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Preface 


The VAX/VMS Release Notes, Version 4.7, describe Version 4.7of the 
VAX/VMS operating system and explain the method for updating a 
Version 4.6 system to Version 4.7. This document lists and discusses changes 
to the system, new features, corrected problems, and restrictions in its use. 


Intended Audience 

This manual contains information of interest to all system users. 


Document Structure 

There are three chapters and one appendix. 

• Chapter 1 contains instructions for installing the Version 4.7 update kit. 

• Chapter 2 briefly summarizes each new or changed system feature. 
Because these release notes supersede the Version 4.4 through 4.6 release 
notes, this chapter describes new or changed features in Versions 4.4 
through 4.7. 

• Chapter 3 details fixes to known problems in the operating system. It 
describes restrictions that should be applied to the use of VAX/VMS 
Version 4.7 and contains miscellaneous technical notes as well. 

• Appendix A lists the contents of the VAX/VMS update kit. 


Associated Documents 

In addition to the documents for which corrections and additions are 
presented in Chapters 2 and 3, you might find the following documents 
helpful while reviewing the new material presented in this manual: 

• The VAX/VMS Supplemental Information, Version 4.7 

• The VAX/VMS System Manager's Reference Manual 

• The Guide to VAX/VMS Software Installation 

• The Guide to VAXclusters 

• The VAX/VMS Operating System, Version 4.7 Software Product Description 
(SPD 25.01.29) 

• The System Software Ordering Table (SPD 28.98.xx) 


xi 






The following conventions are observed in this document: 


Convention 

Meaning 

IretI 

In examples, a key name (usually abbreviated) 
shown within a box indicates that you press 
a key on the keyboard; in text, a key name is 
not enclosed in a box. In this example, the key 
is the RETURN key. (Note that the RETURN 
key is not usually shown in syntax statements 
or in all examples; however, assume that you 
must press the RETURN key after entering a 
command or responding to a prompt.) 

CTRL/C 

A key combination, shown in uppercase with a 
slash separating two key names, indicates that 
you hold down the first key while you press the 
second key. For example, the key combination 
CTRL/C indicates that you hold down the key 
labeled CTRL while you press the key labeled C. 
In examples, a key combination is enclosed in a 
box. 

$ SHOW TIME 

05-JUN-1988 11:55:22 

In examples, system output (what the system 
displays) is shown in black. User input (what 
you enter) is shown in red. 

$ TYPE MYFILE.DAT 

In examples, a vertical series of periods, or 
ellipsis, means either that not all the data that 
the system would display in response to a 
command is shown or that not all the data a 
user would enter is shown. 

input-file, . . . 

In examples, a horizontal ellipsis indicates 
that additional parameters, values, or other 
information can be entered, that preceding 
items can be repeated one or more times, or 
that optional arguments in a statement have 
been omitted. 

[logical-name] 

Brackets indicate that the enclosed item is 
optional. (Brackets are not, however, optional 
in the syntax of a directory name in a file 
specification or in the syntax of a substring 
specification in an assignment statement.) 

quotation marks 
apostrophes 

The term quotation marks is used to refer 
to double quotation marks ("). The term 
apostrophe (') is used to refer to a single 
quotation mark. 






Installing the Version 4.7 Update Kit 


This chapter describes the procedures necessary for installing the Version 4.7 
update to the VAX/VMS operating system. When you install the update kit, 
a Version 4.7 system is produced. 


The Version 4.7 Kit 

The VAX/VMS Version 4.7 update kit consists of documentation, patches, 

and replacement files. It includes the following components: 

• The VAX/VMS Operating System, Version 4.7 Software Product Description 

(SPD 25.01.29) 

• The VAX/VMS Release Notes, Version 4.7 

• The VAX/VMS Supplemental Information, Version 4.7. 

• Distribution media in one of the following formats: 

— Nine-track, 1600 bpi magnetic tape for all processors, including the 
VAX 8530, VAX 8550, VAX 8600, VAX 8650, VAX 8700, and VAX 
8800 processors. 

— Three RX50 diskettes for the VAX 8200, VAX 8250, VAX 8300, and 
VAX 8350 processors. 

— Four RX01 diskettes for the VAX-11/780, VAX-11/782, or 
VAX-11/785 processors. 

— Four TU58 cassettes for the VAX-11/725, VAX-11/730, and 
VAX-11/750 processors. 

— One TK50 tape cartridge for MicroVAXs and VAXstations that serve 
as boot nodes for Local Area VAXclusters. 

— One CDROM for VAXstations that serve as boot nodes for Local Area 
VAXclusters. (These release notes do not describe how to update 
to Version 4.7 from CDROM. See the leaflet supplied with your 
CDROM for special instructions.) 

The software distribution media is composed of three save sets. Save-set 
A contains fixes that apply to both VAX/VMS and MicroVMS. Save-set B 
contains VMS-specific fixes and save-set C contains Micro VMS-specific fixes. 
The VMSINSTAL command procedure determines whether you are updating 
a VAX/VMS or a MicroVMS system and automatically applies the correct 
save sets. 

Appendix A lists the patches, new images, and fixes contained in the 
Version 4.7 update kit. 
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Installing the Version 4.7 Update Kit 

1.1 The Version 4.7 Kit 


1.1.1 Optional Software Products 

Version 4.7 affects the following optional software products: 

• Local Area VAXcluster License Key — You must reinstall the license key 
for a Local Area VAXcluster after installing the Version 4.7 update. 

• Volume Shadowing License Key — You must reinstall the volume 
shadowing license key after installing the Version 4.7 update. 

• Workstation Software Product (VWS) — After installing the Version 4.7 
update on your workstation, you must reinstall the Workstation Software 
product (VWS). 

For more information about optional software products, see the System 

Software Ordering Table (SPD 28.98.xx). Documentation for a specific optional 

software product is shipped with that product. 


1.1.2 Requirements 


The following cautions and restrictions must be observed for this update: 

• The system must be running Version 4.6 prior to the application of the 

Version 4.7 update kit: 

— If the system being updated is not currently running VAX/VMS 
Version 4.6, you must upgrade it to Version 4.6 and install the 
Version 4.6 mandatory update before installing the Version 4.7 
update kit. 

— If you are installing the VAX/VMS operating system on a new 
system, you must install Version 4.6 and the Version 4.6 mandatory 
update before installing the Version 4.7 update. 

— If your processor is a Micro VAX 3500, a Micro VAX 3600, a VAXstation 
3200, or a VAXstation 3500 and you received the Version 4.6A kit, 
you must perform the following steps: 

1 Install Version 4.6 and the Version 4.6 mandatory update. 

2 Install the Version 4.6A update kit. 

3 Install the Version 4.7 update kit. This produces a Version 4.7A 
system, although all system messages, including the message 
you receive when you bootstrap the system, indicate that you are 
using Version 4.7. Section 2.1.1 contains instructions for changing 
the system welcome message to read Version 4.7A. 

If your processor is a Micro VAX 3500, a Micro VAX 3600, a VAXstation 
3200, or a VAXstation 3500 and you received the Version 4.7A kit, 
you must perform the following steps: 

1 Install Version 4.6 and the Version 4.6 mandatory update. 

2 Install the Version 4.7 update kit. 

3 Install the Version 4.7A update kit. When you bootstrap the 
system, the message will state that you are using VAX/VMS 
Version 4.7A. All other system messages will indicate that you 
are using VAX/VMS Version 4.7. 
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Installing the Version 4.7 Update Kit 

1.1 The Version 4.7 Kit 


• If you are updating a system in which the system disk is a shadow set 
member, see Section 4.4 of the VAX/VMS Volume Shadowing Manual 
before performing the update. Section 4.4 describes tasks to complete 
before applying the update to such a disk. After you finish the update, 
you must reapply the volume shadowing key. 


1.2 How to Proceed 

Proceed to Section 1.3 if you are updating a VAXcluster. Proceed to 
Section 1.4 if you are updating a Local Area VAXcluster. Proceed to 
Section 1.5 if you are updating a standalone system. 


1.3 Applying Updates to VAXcluster Systems 

The high degree of sharing achieved among systems in a VAXcluster 
environment is the result of coordination at many levels of the VAX/VMS 
operating system. This level of coordination generally cannot be achieved 
across major or minor releases of the VAX/VMS operating system. Hence, 
all members of a VAXcluster system must run the same version (major and 
minor) of the VAX/VMS operating system. In addition, VAXcluster sites must 
be prepared to update all VAX systems in a cluster at the same time. 

An understanding of the following terms is useful in understanding the 
discussions in this section: 

Common system root Directory structure, residing on a common system 

disk, containing the system files shared by several 
processors in a cluster environment 

Private system root Directory structure, residing in either a private or a 

shared system disk, in which the system files are 
used by a single processor in a cluster environment 

System root Generic term referring to either a common system 

root or a private system root 

VAX/VMS Version 4.7 (or 4.7A) cannot coexist in a cluster with Version 4.5 
or earlier versions of the operating system. Versions 4.7 (or 4.7A) and 4.6 
(or 4.6A) may be intermixed in VAXcluster configurations but only for the 
purposes of incrementally updating the various systems in the cluster and 
testing the newly installed operating system on VAXcluster members. 

During the time that two versions of the VAX/VMS operating system are 
operating in a cluster, you must consider the following factors: 

• All systems booted from a common system root must run the same 
VAX/VMS version. 

• When a VAX/VMS Version 4.7 system boots in the presence of a 
Version 4.6 or 4.6A system, the system console displays the following 
informational message: 

'/.CSP-I-DIFSWVER, different versions of VAX/VMS exist in cluster 

• You should complete the update from Version 4.6 to Version 4.7 on all 
system roots of the cluster as quickly as possible. 
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Installing the Version 4.7 Update Kit 

1.3 Applying Updates to VAXcluster Systems 


Given these restrictions, there are two methods of applying the update to an 
entire cluster: 

Rolling update Use this method for a VAXcluster site having multiple 

system roots (that is, any combination of private system 
roots and common system roots). This method enables 
old and new versions to temporarily exist together in the 
same VAXcluster system as you apply the update to each 
system root. (See Section 1.3.1.) 

Concurrent update Use this method for a VAXcluster site that has a single 
common system root. The entire cluster is unavailable as 
the update is applied to the common system root. When 
the update has been completed, reboot each node in the 
cluster to run the updated version. (See Section 1.3.2.) 

When updating a common system root during either a rolling update or a 
concurrent update, you need to perform only one complete update from one 
of the nodes that shares the common system root. However, you may need 
to modify the console boot command files and manually invoke AUTOGEN 
to update the system configuration parameters for all nodes that share the 
common system root. Alternatively, you can use the MAKEROOT command 
procedure to create new alternate roots for these nodes. (See the Guide to 
VAXclusters for additional information.) 


1.3.1 Updating a VAXcluster Environment: Rolling Update 

A rolling update is the method used to apply an update to a VAXcluster 
system having multiple system roots (that is, any combination of private 
and common system roots). In a rolling update, you apply the update to 
each system root individually, thus causing new and old VAX/VMS versions 
to exist together temporarily in the same VAXcluster. As a result, a rolling 
update maintains partial system availability during an update. (See Chapter 5 
of the Guide to VAXclusters for additional information.) 

A rolling update is not applicable when all systems boot from a single 
common system root. If all systems boot from a single common system root, 
you must perform a concurrent update, as described in Section 1.3.2. 

To perform a rolling update, complete the following steps, as appropriate, for 
each common system root or private system root in the cluster: 

1 Check the value of the system parameter VOTES and make adjustments 
to maintain the proper quorum. This allows the cluster to continue 
operating throughout this process. (Chapter 5 of the Guide to VAXclusters 
describes this procedure in detail.) 

2 Complete all the steps in Section 1.5 of these release notes. 

If you are updating a private system root, skip the rest of this step and go 
to step 3. 

If you are updating a common system root, you need to perform only one 
complete update from one of the nodes that shares that root. For all 
systems on a common system root, except the one from which you will 
apply the update, perform the following actions: 

a. Shut down the system, using your site's standard shutdown 
procedure. (See Section 4.1.1 of the VAX/VMS System 
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Manager's Reference Manual for a description of the 
SYS$SYSTEM:SHUTDOWN.COM command procedure.) 

b. After you shut down a system on a common system root, enter the 
following command on one of the remaining nodes: 

$ SET CLUSTER/QUORUM 

This allows one node to continue running from the common system 
root (assuming other nodes running from different roots supply 
enough votes to sustain cluster quorum). 

If proper quorum is not maintained, the shutdown procedure will 
hang the cluster. In this event, enter the following commands to free 
the cluster: 

$ |CTRL/P| 

»>H 

»>D/I 14 C 

»>C 

IPC>Q 

IPO I CTRL/ Z | 

3 Update the single system according to Section 1.6 of these release notes. 

4 Manually reboot the updated system, as described in Section 4 of the 
VAX/VMS System Manager's Reference Manual. The updated version 
should now be running on the single system. 

When updating a common system root, reboot the other systems from the 
updated common root. This allows all systems on the common system 
root to run the updated version. 

Note: At this point, the cluster is running with mixed versions of the 

VAX/VMS operating system. You should now test and verify the new 
version before updating the other system roots. 

5 Repeat the tasks in this section, as appropriate for each system root, until 
all roots are running the updated version. 

6 Proceed to step 2 of Section 1.7. 


1.3.2 Updating a VAXcluster Environment: Concurrent Update 

A concurrent update is the method used to apply an update to a VAXcluster 
environment that has a single common system root. A concurrent update 
is performed by shutting down the entire cluster and applying the updated 
version to the common system root. When the update is complete, you boot 
each node in the cluster to start running the updated VAX/VMS version. 

All systems in the cluster are unavailable while a concurrent update is being 
performed. 

Perform the following steps to perform a concurrent update on your 
VAXcluster system: 

1 Shut down the entire cluster, using your site's standard shutdown 

procedure. (See Section 4.1.1 of the VAX/VMS System Manager’s Reference 
Manual for a description of the SYS$SYSTEM:SHUTDOWN.COM 
command procedure.) 
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2 Perform a conversational boot on a single VAX system. Note the current 
values for the VOTES and QUORUM parameters; you will restore these 
values after the update has completed. Set the value for the VOTES and 
QUORUM parameters to 1. Enter the following commands to note the 
current values of the VOTES and QUORUM parameters and to set them 
to 1: 

SYSB00T> SHOW VOTES 
SYSB00T> SHOW QUORUM 
SYSB00T> SET VOTES 1 
SYSB00T> SET QUORUM 1 
SYSB00T> CONTINUE 

See Section 4.2.3 of the VAX/VMS System Manager's Reference Manual for 
further discussion of the conversational boot procedure. Chapter 5 of the 
Guide to VAXclusters contains additional information about the VOTES 
and QUORUM parameters. 

3 Install the Version 4.7 update as described in Sections 1.5 and 1.6. This 
applies the update to the root from which the system is booted. The 
update procedure shuts down the system when it completes. 

4 Perform a conversational boot of this system, entering the necessary 
SYSBOOT commands to restore the original settings of the system 
parameters VOTES and QUORUM on this system as recorded in step 2. 

5 Reboot the entire cluster according to your normal operating procedures. 
The entire cluster is now running the updated version of the VAX/VMS 
operating system. 

6 Proceed to step 2 of Section 1.7. 


1.4 Applying Updates to Local Area VAXcluster Systems 

Before starting the update on a Local Area VAXcluster system, note the 

following: 

• Read the release notes in Appendix C of the Local Area VAXcluster 
Manual , Version 4.6. 

• All satellite nodes must be shut down for the duration of the update. 

If possible, perform an orderly shutdown by invoking the command 
procedure SYS$SYSTEM:SHUTDOWN.COM. When the procedure asks if 
you want an automatic reboot, answer NO. If for some reason you cannot 
perform an orderly shutdown, halt the satellite node by pressing and 
releasing the HALT button on the satellite node's processor control panel 
or by pressing the BREAK key on the satellite node's console terminal. 

• After the update completes, you must reinstall the Local Area VAXcluster 
license key (LAV010) and then reboot all the satellite nodes. 

• If you are upgrading a Micro VMS operating system to the VAX/VMS 
operating system, to use a Micro VAX system as a boot node in a Local 
Area VAXcluster, you can delete SYS$SYSTEM:UVSTARTUP.COM after 
the upgrade completes. 

Sections 1.4.1 through 1.4.3 describe procedures for updating specific Local 

Area VAXcluster configurations. 
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1.4.1 Updating a Configuration with One Boot Node and One System Disk 

Figure 1-1 shows a local area VAXcluster with one boot node and one system 
disk. 

Figure 1 -1 Local Area VAXcluster with One Boot Node and One 
System Disk 
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To update this Local Area VAXcluster configuration, proceed as follows: 

1 Shut down all satellite nodes. 

2 Log in to the system manager's account (SYSTEM) on the boot node. 

3 Follow the steps in Section 1.5 to prepare your system for the update. 

4 Apply the Version 4.7 update, as described in Section 1.6. 

5 Reboot the boot node. If your boot node is a Micro VAX, see the software 
installation guide for your processor for instructions. If your boot node 
is not a MicroVAX, see Section 4 of the VAX/VMS System Manager's 
Reference Manual for instructions. 

6 Insert the media containing the Local Area VAXcluster license key into 
the appropriate drive and enter the following command at the boot node 
to reinstall the license key: 

$ @SYS$UPDATE:VMSINSTAL LAV010 ddcu: 

The parameter ddcu is the physical device name of the drive from which 
you reinstall the license key. 

7 Reboot the boot node. 

8 Restore the values of system parameters. If you modified the values of 
GBLSECTIONS and GBLPAGES in step 4 of Section 1.5, you might want 
to restore the old values. Edit SYS$SYSTEM:MODPARAMS.DAT and 
delete the ADD_GBLSECTIONS and ADD_GBLPAGES lines to restore 
the old values of these parameters. 
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9 Run the AUTOGEN procedure on the boot node to adjust system 
parameters. Enter the following command, which runs AUTOGEN, 
shuts down the system, and reboots the system: 

$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT 

10 Reboot the satellite nodes, one at a time. 

11 Run the AUTOGEN procedure on each satellite node to adjust system 
parameters. Enter the following command, which runs AUTOGEN, shuts 
down the system, and reboots the system: 

$ OSYSSUPDATE:AUTOGEN SAVPARAMS REBOOT 

12 Perform step 2 in Section 1.7 to free up space on the system disk. 


1.4.2 Updating a Configuration with One Boot Node and Two System Disks 

Figure 1-2 shows a local area VAXcluster with one boot node and two system 
disks. 

Figure 1-2 Local Area VAXcluster with One Boot Node and Two 
System Disks 
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To update this Local Area VAXcluster configuration, proceed as follows: 

1 Shut down all satellite nodes. 

2 Log in to the system manager's account (SYSTEM) on the boot node. 

3 Follow the steps in Section 1.5 to prepare your system for the update. 

4 Apply the Version 4.7 update, as described in Section 1.6. 

5 Reboot the boot node. 
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6 Insert the media containing the Local Area VAXcluster license key into 
the appropriate drive and enter the following command at the boot node 
to reinstall the license key: 

$ @SYS$UPDATE:VMSINSTAL LAV010 ddcu: 

The parameter ddcu is the physical device name of the drive from which 
you reinstall the license key. 

7 Reboot the boot node. 

8 Restore the values of system parameters. If you modified the values of 
GBLSECTIONS and GBLPAGES in step 4 of Section 1.5, you might want 
to restore the old values. Edit SYS$SYSTEM:MODPARAMS.DAT and 
delete the ADD—GBLSECTIONS and ADD_GBLPAGES lines to restore 
the old values of these parameters. 

9 Run the AUTOGEN procedure on the boot node to adjust system 
parameters. Enter the following command, which runs AUTOGEN, 
shuts down the system, and reboots the system: 

$ OSYSSUPDATE:AUTOGEN SAVPARAMS REBOOT 

10 The first system disk is now updated. To update the second disk, follow 
these steps: 

a. Boot a satellite node that runs off the second system disk. 

b. When the satellite node comes up, log in to the system manager's 
account (SYSTEM) on the satellite node. 

c. Apply the Version 4.7 update, this time following instructions in 
Section 2.5.5 of the VMS Local Area VAXcluster Manual , "Installing 
Layered Products on a Boot Node with a Second System Disk." Note 
that the product name is VMS047. 

d. Because the update deletes PEDRIVER.EXE, the reboot phase of 
the upgrade cannot complete on the second disk until PEDRIVER 
is restored. To restore the driver, log in to the boot node and copy 
the driver to the second disk. For example, if the second disk is 
SANDY$DUA1, you would enter the following command: 

$ COPY SYS$C0MM0N:[SYSEXEjPEDRIVER.EXE SANDY$DUA1:[V4C0MM0N.SYSEXE] 

Once the driver has been copied, the update reboot phase will 
complete normally. 

11 Reboot the remaining satellite nodes, one at a time. 

12 Run the AUTOGEN procedure on each satellite node to adjust system 
parameters. Enter the following command, which runs AUTOGEN, shuts 
down the system, and reboots the system: 

$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT 

13 Perform step 2 in Section 1.7 to free up space on both system disks. 
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1.4.3 Updating a Configuration with Two Boot Nodes and Two System Disks 

Figure 1-3 shows a local area VAXcluster with two boot nodes and two 
system disks. 

Figure 1-3 Local Area VAXcluster with Two Boot Nodes and Two 
System Disks 
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To update this Local Area VAXcluster configuration, proceed as follows: 

1 Shut down all satellite nodes. 

2 Shut down both boot nodes. 

3 Configure one boot node to run standalone. Initiate a conversational 
bootstrap operation, * 1 2 3 4 5 6 7 and enter the following commands at the 
SYSBOOT> prompt: 

SYSB00T> SET QUORUM 1 
SYSB00T> CONTINUE 

4 After the system bootstraps, follow the steps in Section 1.5 to prepare 
your system for the update. 

5 Log in to the system manager's account (SYSTEM) and apply the 
Version 4.7 update, as described in Section 1.6. 

6 Reboot the first boot node. 

7 Insert the media containing the Local Area VAXcluster license key into 
the appropriate drive and enter the following command to reinstall the 
license key: 

$ @SYS$UPDATE:VMSINSTAL LAV010 ddcu: 



1 See the appropriate VAX/VMS system management documentation or the VAX/VMS installation and operations 
guides supplied with your processor for an explanation of the conversational bootstrap operation. 


1-10 
























Installing the Version 4.7 Update Kit 

1.4 Applying Updates to Local Area VAXcluster Systems 


The parameter ddcu is the physical device name of the drive from which 
you reinstall the license key. 

8 Invoke the System Generation Utility (SYSGEN), as follows, to reset 
QUORUM to 2 for the next boot: 

$ RUN SYSSSYSTEM:SYSGEN 
SYSGEN> USE CURRENT 
SYSGEN > SET QUORUM 2 
SYSGEN > WRITE CURRENT 
SYSGEN> EXIT 

9 Restore the values of system parameters. If you modified the values of 
GBLSECTIONS and GBLPAGES in step 4 of Section 1.5, you may want 
to restore the old values. Edit SYS$SYSTEM:MODPARAMS.DAT and 
delete the ADD—GBLSECTIONS and ADD—GBLPAGES lines to restore 
the old values of these parameters. 

10 Run the AUTOGEN procedure on the boot node to adjust system 
parameters. Enter the following command, which runs AUTOGEN 
and shuts down the system, and reboots the system: 

$ OSYSSUPDATE:AUTOGEN SAVPARAMS REBOOT 

11 Repeat steps 3 through 10 on the other boot node. 

12 Reboot both boot nodes. 

13 Reboot the satellite nodes, one at a time. 

14 Run the AUTOGEN procedure on each satellite node to adjust system 
parameters. Enter the following command, which runs AUTOGEN, shuts 
down the system, and reboots the system: 

$ OSYSSUPDATE:AUTOGEN SAVPARAMS REBOOT 

1 5 Perform step 2 in Section 1.7 to free up space on both system disks. 


1.5 Preparing to Update Your System 

This section describes the activities you must perform before applying the 
Version 4.7 update to your system. You should read this entire section before 
proceeding with the update. 

Perform the following steps to prepare your system for the update: 

1 Reserve space for the update files. 

The VAX/VMS Version 4.7 update procedure requires that a minimum 
number of free blocks be available on the system disk to allow the 
procedure to properly perform the update. To ensure that there are 
sufficient free blocks to meet the update procedure's peak disk block 
utilization (see Table 1-1), perform the following actions: 

a. Confirm the number of free blocks on the system disk by entering the 
following DCL command: 

$ SHOW DEVICE SYS$SYSDEVICE: 
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b. Compare the number of free blocks shown on the display against the 
required peak disk block utilization shown in Table 1-1. 

Table 1-1 Approximate Disk Block Utilization for Version 4.7 
Update Procedure 


Peak disk block utilization 
Net disk block utilization if files 


6700 

2800 


are purged during the update 


If you have fewer blocks available than the peak disk block utilization 
figure, you must reduce the number of used disk blocks to acquire enough 
free space for the Version 4.7 update. DIGITAL recommends that you use 
the following procedure to gain the needed disk space: 

a. Log in to an account that has sufficient privileges to create space 
on the system disk. DIGITAL recommends that you do not log 
in to the SYSTEM account. The SYSTEM account, which has 
all privileges (including BYPASS), is intended only for software 
installation, bootstrapping, and system problem diagnosis. You 
can avoid problems by creating another account and assigning the 
minimum privileges required to this account. 

b. Delete or purge all unwanted or redundant files from the system disk. 

c. If there still is not enough available space, copy the following files to 
another media and delete them from the system disk: 


• All files with file types of JNL, MAP, and LOG 

• All files in the [SYSHLP.EXAMPLES] and [SYSTEST] directories 

If you cannot make a sufficient number of free blocks available on the 
system disk to meet peak utilization requirements, the update procedure 
operates in an alternate mode that reduces these requirements. However, 
if a system failure occurs while the procedure is operating in this alternate 
mode, you must restore the Version 4.6 system disk from a backup copy 
and restart the update procedure from the beginning. 

2 Back up and restore the system disk. 

By backing up the system disk, you preserve the original system disk in 
the event that a system failure at a critical point in the update results 
in unusable or deleted files. Restoring the system disk improves disk 
performance by storing all files contiguously and making all free disk 
space contiguous. 

CAUTION: If you elect not to back up your system disk, a system failure at a 


critical point of the update procedure may cause the previous contents 
of the disk to become irretrievable. 

To back up the system disk, proceed as follows: 

a. Use standalone BACKUP as described in the Guide to VAX/VMS 
Software Installation or in the VAX/VMS System Manager's Reference 
Manual. 
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b. If an additional drive with an unused disk of equal capacity is 
available, you can perform a disk-to-disk backup directly to it from 
the system disk and use the backup as the system disk during the 
update. To do this, you must swap the unit plugs of the two drives 
so that you can boot from the new backup disk using the default 
command procedure, DEFBOO. 

If no drive with a disk of equal capacity is available, you must back 
up the system disk to whatever device is available: 

• If the system disk is removable, remove and replace it with a 
spare disk. Then, transfer the files from the backup device to 
the spare disk by performing another backup operation. Use the 
spare disk as the system disk for the update and preserve the 
original system disk. 

• If the system disk is not removable, you must use the original 
system disk for the update. However, you should restore 
the backup from the backup device to the system disk before 
performing the update to ensure that there is sufficient contiguous 
free space on the disk. 

3 Back up the console RL02 disk. 

If you are updating a VAX 8600 or VAX 8650 system, DIGITAL 
recommends that you also back up the console RL02 disk before applying 
the update. To do so, follow the steps in Section 2.8.1.1 of the VAX/VMS 
System Manager's Reference Manual, substituting "VAX 8600" for 
"VAX-11/780" and "RL02 disk" for "diskette" throughout the section. 

4 Confirm the quotas and limits of the SYSTEM account. 

Because you install the update from the SYSTEM account, you must 
make sure that the account has sufficient quotas and limits to complete 
the update successfully. To do so, perform the following actions: 

a. Log in to the SYSTEM account. 

b. Run the Authorize Utility (AUTHORIZE) by entering the following 
commands: 

$ SET DEFAULT SYS$SYSTEM 
$ RUN AUTHORIZE 
UAF> SHOW SYSTEM 

c. Compare the SYSTEM account's limits and quotas to the following 
values: 


Open file quota (Fillm) 

60 

Buffered I/O limit (BlOlm) 

18 

Direct I/O limit (DIOIm) 

18 

AST limit (ASTIm) 

24 

Enqueue quota (Enqlm) 

30 

Buffered byte quota count (Bytlm) 

20480 

Adjust the limits and quotas, as needed, to ensure that they are equal 
to or greater than the required values. You can change each value by 
entering a command in the following format: 

UAF> MODIFY SYSTEM/1imit=new_value 
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For example: 

UAF> MODIFY SYSTEM/DI0LM=18 

e. Return to DCL command level by entering the following command: 
UAF> EXIT 

f. If you adjust any of the SYSTEM account's values, log out and log in 
again so that the new values take effect. 

5 Reserve sufficient global pages and global sections. 

The installation procedure requires at least 50 unused global sections 
and 3000 unused global pages. Make sure that sufficient unused global 
sections and global pages are available to the procedure by performing 
the following operations: 

a. Display the number of used global sections and used and unused 
global pages by entering the following commands: 

$ INSTALL :== $INSTALL/C0MMAND_M0DE 
$ INSTALL 

INSTALL> LIST/GLOBAL/SUMMARY 
INSTALL> EXIT 

b. Determine the current number of global sections by invoking the 
System Generation Utility (SYSGEN) and entering the following 
commands: 

$ RUN SYSSSYSTEM:SYSGEN 
SYSGEN> USE CURRENT 
SYSGEN> SHOW GBLSECTIONS 
SYSGEN> EXIT 

c. Determine the number of unused global sections by subtracting 
the number of used global sections (determined in step a from 
the INSTALL display) from the current number of global sections 
(determined in step b from the SYSGEN display). 

d. If the number of unused global sections is less than 50, add the 
following line to SYS$SYSTEM:MODPARAMS.DAT: 

ADD_GBLSECTI0NS = 50 

e. If the number of unused global pages (determined in step a from 
the INSTALL display) is less than 3000, add the following line to 
SYS$SYSTEM:MODP ARAMS.DAT: 

ADD.GBLPAGES = 3000 

f. Run the AUTOGEN procedure if you added a line to 
MODPARAMS.DAT to modify the GBLPAGES or GBLSECTIONS 
parameter. Enter the following command to run the AUTOGEN 
procedure: 

$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT 

The previous command shuts down the system and reboots it. After 
the system reboots, log in to the system manager's account, SYSTEM. 
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6 Isolate the system from users. 

Make sure that you are the only user logged in to the system. This is a 
twofold procedure: 

a. Notify current users that they must log out. 

b. Prevent new users from logging in by entering the following 
command: 

$ SET LOGINS/INTERACTIVE=0 

7 Shut down the network. 

Perform this task only if your system is running DECnet-VAX software. 

If you are not sure whether your system includes DECnet-VAX software, 
enter the following command: 

$ SHOW NETWORK 

If the message "%SHOW-I-NONET, network unavailable" appears, skip 
to the next step. If your system does include DECnet-VAX software, shut 
it down by entering the following commands: 

$ RUN SYS$SYSTEM:NCP 
NCP> SET EXECUTOR STATE OFF 
NCP> EXIT 

8 Stop all batch and print queues. 

To do so, perform the following tasks: 

a. Enter the following command to determine the state of all system 
queues: 

$ SHOW QUEUE/DEVICE/BATCH/FULL/ALL 

b. Stop each active queue by entering the following command: 

$ STOP/QUEUE/NEXT queue.name 

The NEXT qualifier allows the current job to complete before the 
system stops the queue. If the current job will take a long time to 
complete, you might want to ask the person who submitted the job if 
it is safe to stop it prior to completion. 

9 Connect the console device. 

If you are installing Version 4.7 from console media, enter the following 
commands to connect the console device: 

$ RUN SYSSSYSTEM:SYSGEN 
SYSGEN> CONNECT CONSOLE 
SYSGEN> EXIT 

10 Review special considerations. 

Under various circumstances and within certain configurations, you might 
be required to perform other actions before proceeding with the update. 
See Section 1.1.2 to determine if any special requirements apply to your 
system. 
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1.6 Installing the Version 4.7 Update 

After completing the procedures described in Section 1.5, perform the steps in 
this section to install the Version 4.7 update kit. 

1 Invoke the VMSINSTAL command procedure. 

Enter the following command: 

$ @SYS$UPDATE:VMSINSTAL VMS047 device-name 

The parameter device-name is the physical name of the device that will 
hold the update distribution media. Use one of the following formats for 
device-name depending on the system configuration: 

• If the distribution volume (or volumes) is to be mounted on a non- 
HSC device, specify device-name using the format ddcu, as follows: 

dd specifies the type of device. 
c refers to the controller number. 
u refers to the device unit number. 

• If the distribution volume (or volumes) is to be mounted on an HSC 
device, specify device-name using the format hsc-name$ddcu. 

For example, if your distribution kit (load device) is a TU80 magnetic tape 
drive on controller A with unit number 0, you would enter the command: 

$ @SYS$UPDATE:VMSINSTAL VMS047 MUAO: 

If you are updating from a TA80 magnetic tape drive controlled by an 
HSC named VICE on controller A with unit number 0, you would enter 
the command: 

$ @SYS$UPDATE:VMSINSTAL VMS047 VICE$MUA0: 

If the VMSINSTAL command fails, determine whether either of the 
following conditions occurred: 

• If VMSINSTAL displays the message r, %VMSINSTAL-E-NOPRODS, 
None of the specified products were found," it is likely that you 
specified the letter "O" in the product name "VMS047" instead of a 
zero. 

• If VMSINSTAL displays an "invalid device" error message, it issues 
prompts for a device name until you specify the correct name of a 
device existing on the system. Remember to terminate the device 
name with a colon (:). 

When the command succeeds, VMSINSTAL displays the following 
message: 

VAX/VMS Software Product Installation Procedure V4.6 
It is (date) at (time). 

Enter a question mark (?) at any time for help. 

2 Reply to VMSINSTAL prompts. 

As the update procedure begins, VMSINSTAL presents its first prompt: 

• Are you satisfied with the backup of your system disk [YES]? 
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If you are content with the current backup of the system disk, press the 
RETURN key and continue. 

If you have not yet backed up your system disk or are otherwise 
dissatisfied with the current backup, perform the following operations: 

a. Type NO and press the RETURN key. VMSINSTAL returns to DCL 
level to permit you to perform the backup. 

b. Back up and restore your system disk using standalone BACKUP 
as described in the Guide to VAX/VMS Software Installation or the 
VAX/VMS System Manager's Reference Manual Preserve your current 
system disk and use the backup copy to verify that the backup copy 
contains a working system. 

If your system is a VAX 8600 or VAX 8650 system and you have not 
backed up the console RL02, DIGITAL recommends that you do so 
now. To do so, follow the steps in Section 2.8.1.1 of the VAX/VMS 
System Manager's Reference Manual substituting "VAX 8600" for 
"VAX-11/780" and "RL02 disk" for "diskette" throughout the section. 

c. Restart the update procedure at step 1 when the backup is 
completed. 

As it proceeds, VMSINSTAL may request additional information from you 
or display various messages. For instance, if you did not specify the name 
of a load device in the command that invoked VMSINSTAL in step 1, 
VMSINSTAL prompts for the name of the device holding the distribution 
volume: 

* Where will the distribution volume be mounted: 

To respond, enter the physical name of the device that will hold the 
distribution media during the update operation. 

VMSINSTAL displays informational messages describing the actions it 
is performing. During the entire process, look for error and warning 
messages that indicate tasks you must perform manually. Many 
informational messages will be displayed; these messages can usually 
be ignored. For example, if you are installing from an operator's terminal, 
you will receive a message after each mount operation if the system 
parameter MOUNTMSG is set and after each dismount operation if 
the system parameter DISMOUMSG is set. Each message will appear 
within 30 seconds of its associated operation. (Note that, by default, the 
MOUNTMSG and DISMOUMSG parameters are not set.) 

3 Mount the first (or only) volume of the update kit. 

VMSINSTAL next displays the following prompt; 

Please mount the first volume of the set on ddcu:. 

* Are you ready? 

To respond, perform the following actions: 

a. Insert the first (or only) distribution volume into the load device. If 
you are installing from diskettes, insert the first volume in the drive. 
If you are installing from magnetic tape, load the tape into the drive 
and press the ONLINE button to put the drive on line. If you are 
installing from TU58 cassettes, insert the first cassette into the drive. 
If you are installing from a tape cartridge, insert the cartridge into the 
tape drive. 
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b. After you insert the first (or only) volume into the appropriate drive, 
type Y and press RETURN. 

VMSINSTAL then displays the following information: 

•/.MOUNT-1-MOUNTED, VMS047 mounted on _ddcu: 

The following products will be processed: 

VMS V4.7 

Beginning installation of VMS V4.7 at (time) 
•/.VMSINSTAL-I-RESTORE, Restoring product saveset A. . . 

c. If you are installing the update from a set of diskette or TU58 cassette 
volumes, VMSINSTAL automatically requests, as it completes its 
operations from one volume, that you remove the current volume and 
insert the subsequent one. 

If you are installing from magnetic tape, there is only one tape for 
you to mount. 

When VMSINSTAL completes the restoration of the save sets, it 
begins to apply the update to the system disk. During this time, 
be sure that the last (or only) volume of the update media remains 
mounted until the update is completed. 

Note: If you are updating a tailored system or a small disk system (for 

example, a system using an RK07 cartridge disk), note that when the 
update procedure creates free disk blocks, it automatically cancels 
the effects of the VAX/VMS Tailoring facility. For this reason, 
the VMSINSTAL command procedure requires, at this time, that 
you mount the library disk so it can save the current tailoring 
environment across the update procedure. 

4 Supply passwords, if prompted, and select an update option. 

Shortly after it copies the first save set from the installation volume (or 
volumes), VMSINSTAL displays the following informational message: 

This kit contains Version 4.7 of VAX/VMS. It must be installed 
upon Version 4.6 of VAX/VMS. 

NOTE: Among the new images shipped in this kit are 

PEDRIVER.MSKEXE and DSDRIVER.MSKEXE. If your 
system is running LAVc or volume shadowing 
software, you MUST reapply the LAVc or volume 
shadowing key(s) AFTER applying the Version 4.7 
update. If you do not reapply the appropriate keys, 
your system will not be running the updated 
images. 

Next, the update procedure checks that each DIGITAL-supplied account 
has an appropriate password and displays messages such as the following 
if the account has no password or if the password is the same as the user 
name of the account. Do not disable the SYSTEM account or the FIELD 
account. You can choose to disable other accounts. 

The first phase of the upgrade will attempt to verify that all Digital 
supplied accounts are secured against obvious penetration attempts. 

UPGRADE-W-PWD_INVALID, account password for SYSTEM is invalid 
-UPGRADE-I-PWD_WEAK, password is too easy to guess 

Because of the preceding error, you must take action to secure this account. 

You must either disable this account, change its password, or do both. 


1-18 


Installing the Version 4.7 Update Kit 

1.6 Installing the Version 4.7 Update 


* Do you want to disable the account [YES]? NO 

* Do you want to change the account password [YES]? YES 

You must now select a new primary password for the SYSTEM account. The 
password you select must be at least 8 characters in length and may not be the 
same as the name of the account. 

New password: Enter the new password; it does not appear on your terminal. 
Verification: Enter the new password again; it does not appear on 
your terminal. 

# / 0 UAF-1-MDFYMSG, user record(s) updated 

# /,UPGRADE-I-PWD_SET, primary password for account SYSTEM set. 

UPGRADE-W-PWD_INVALID, account password for FIELD is invalid 
-UPGRADE-I-PWD_WEAK, password is too easy to guess 

Because of the preceding error, you must take action to secure this account. 
You must either disable this account, change its password, or do both. 

* Do you want to disable the account [YES]? NO 

* Do you want to change the account password [YES]? YES 

You must now select a new primary password for the FIELD account. The 
password you select must be at least 8 characters in length and may not be the 
same as the name of the account. 

New password: Enter the new password; it does not appear on your terminal. 
Verification: Enter the new password again; it does not appear on 
your terminal. 

°/ 0 UAF -1 -MDFYMSG, user record(s) updated 

# /,UPGRADE-I-PWD_SET, primary password for account FIELD set. 

UPGRADE-W-PWD_INVALID, account password for SYSTEST is invalid 
-UPGRADE-I-PWD_WEAK, password is too easy to guess 

Because of the preceding error, you must take action to secure this account. 
You must either disable this account, change its password, or do both. 

* Do you want to disable the account [YES]? NO 

* Do you want to change the account password [YES]? YES 

You must now select a new primary password for the SYSTEST account. The 
password you select must be at least 8 characters in length and may not be the 
same as the name of the account. 

New password: Enter the new password; it does not appear on your terminal. 
Verification: Enter the new password again; it does not appear on 
your terminal. 

7.UAF-1-MDFYMSG, user record(s) updated 

'/,UPGRADE-1-PWD_SET, primary password for account SYSTEST set. 

UPGRADE-W-PWD_INVALID, account password for SYSTEST.CLIG is invalid 
-UPGRADE-I-PWD_WEAK, password is too easy to guess 

Because of the preceding error, you must take action to secure this account. 
You must either disable this account, change its password, or do both. 

* Do you want to disable the account [YES]? NO 

* Do you want to change the account password [YES]? YES 

You must now select a new primary password for the SYSTEST.CLIG account. The 
password you select must be at least 8 characters in length and may not be the 
same as the name of the account. 

New password: Enter the new password; it does not appear on your terminal. 
Verification: Enter the new password again; it does not appear on 
your terminal. 
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%UAF-I-MDFYMSG, user record(s) updated 

'/,UPGRADE-1-PWD.SET, primary password for account SYSTEST_CLIG set. 

•/.UPGRADE-1-NONEXIST, account USER does not exist 
•/.UPGRADE-I-NONEXIST, account USERP does not exist 

Next, the system asks you to choose an update option. 

1) Apply all fixes to the system 

2) Create a file with the descriptions of all fixes 

3) Both of the above 

• What would you like to do [3]: 

• Under option 1, VMSINSTAL performs only the update. 

• Under option 2, VMSINSTAL does not perform the update. It simply 
creates the update description file, SYS$UPDATE:VMS047.TXT. 
(Appendix A lists the contents of this file.) 

• Under option 3, VMSINSTAL performs the update and creates the 
update description file. 

Type one of these option numbers and press RETURN. 

If you choose option 2 or 3, VMSINSTAL displays the following message: 
•/.VMS-I-FIXDESC, The fixes are described in SYS$UPDATE:VMS047.TXT 

5 Proceed with the update. 

If you elect to proceed with the update by specifying option 1 or 3, 
VMSINSTAL displays the following question: 

• Do you want to purge files replaced by this installation [YES]? 

If you want VMSINSTAL to automatically purge files replaced by the 
update, press RETURN. Answer N if you do not want these files purged. 
When VMSINSTAL receives your reply to this prompt, it restores the 
remainder of the update save sets and continues the copy operation from 
the specified drive. 

As VMSINSTAL proceeds, it displays the name of each image that is 
patched or installed, plus various informational messages describing the 
characteristics of the patches and images. You should be aware of the 
following situations, which result in messages: 

• The Patch Utility commonly generates the following informational 
messages: 

•/.PATCH-I-NOLCL, image does not contain -local symbols 
•/.PATCH-I-NOGBL, some or all global symbols not accessible 
“/.PATCH-I-PREVINIT, patch area has previously been initialized 

These messages are a normal result of the construction of some 
update patches and should be ignored. 

• When updating an image that has already been patched, VMSINSTAL 
displays the following informational message: 

•/.PATCH-I-ECOSET, eco level nn already set in ' xxx$R00T: filename' 

This message indicates that a patch has previously been applied, most 
likely during the application of the Version 4.6 mandatory update. 

For this reason, you can ignore messages of this sort. 
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If all of the supplied patches in an image have already been applied, 
VMSINSTAL additionally displays the warning message: 

°/ # VMSINSTAL-W-NOFILE, New file 'Filename' does not exist. 

In other words, if all the necessary patches have already been made 
to the file, there is no need for VMSINSTAL to create a new version 
of the file. 

At its completion, VMSINSTAL displays the following message 
advising you to review the various fixes in which it encountered the 
"NOFILE" warning message. You can ignore this message. 

°/ 0 VMS-E-ERRORS, Of the nn fixes listed above, the following nn should be 
reviewed 

VMSINSTAL also creates a journal file (with a JNL file type) for each 
image that is patched during the update process. (See Section 1.8 for 
additional information on the JNL files produced by the Version 4.7 
update.) 

When it completes the update, VMSINSTAL displays the following 
message: 

Installation of VMS V4.7 completed at (time) 

VMSINSTAL then performs an orderly shutdown of the system. 


1.7 Tasks to Perform After the Version 4.7 Update 

After VMSINSTAL has completed its installation of the Version 4.7 update 
kit, DIGITAL recommends that you perform the following tasks: 

1 Reboot the system. 

Manually reboot the system as described in Section 4 of the VAX/VMS 
System Manager's Reference Manual. 

2 Log in to the system manager's account, SYSTEM. 

3 Free up disk space. 

VMSINSTAL permanently uses a certain number of disk blocks (as 
described in Table 1-1) called the net disk block utilization. This figure can 
vary, depending on whether or not you chose (in step 4 of Section 1.6) to 
purge the old copies of system files that are replaced during the update. 

Use the following methods to free up disk space: 

a. Confirm the free block count by entering the following command: 

$ SHOW DEVICE SYS$SYSDEVICE: 

b. Purge those files that the Version 4.7 update procedure cannot purge. 
In this manner you can recover approximately 2000 disk blocks. Use 
the PURGE command to remove old versions of the following files: 

• SYS$LIBRARY:ERFCTLSHR.EXE 

• SYS$LIBRARY:SECURESHR.EXE 

• SYS$SYSTEM:BACKUP.EXE 
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• SYS$SYSTEM:CTDRIVER.EXE 

• SYS$SYSTEM:ERFPROCl .EXE 

• SYS$SYSTEM:HCSPAD.EXE 

• SYS$SYSTEM:MTAAACP.EXE 

• SYS$SYSTEM:PEDRIVER.MSKEXE 

• SYS$SYSTEM:RMS.EXE 

• SYS$SYSTEM:STABACKUP.EXE 

• SYS$SYSTEM:SYS.EXE 

4 Use the Verify Utility to determine if the update procedure purged 
files incompletely. 

When the update procedure purges files automatically, it incompletely 
purges some files used by system processes. System processes are not 
disconnected until the system is shut down. 

The Verify Utility determines if there are any inconsistent files on a disk. 
Enter the following command to determine if your system disk contains 
any partially-purged files: 

$ ANALYZE/DISK.STRUCTURE ddcu: 

The parameter ddcu is the device name of your system disk. 

The Verify Utility issues the following error message if files were purged 
incompletely: 

7 # VERIFY-I-DELHEADER, file 'file-header 1 'file-name' marked for delete 

If the Verify Utility issues this error, enter the following command to 
repair your system disk: 

$ ANALYZE/DISK_STRUCTURE ddcu:/REPAIR 

The parameter ddcu is the device name of your system disk. 

See the VAX/VMS Verify Utility Reference Manual for more information. 

5 Restore the values of system parameters. 

If you modified the values of GBLSECTIONS and GBLPAGES in step 4 
of Section 1.5, you might want to restore the old values at this time. Edit 
SYS$SYSTEM:MODPARAMS.DAT and delete the ADD_GBLSECTIONS 
and ADD_GBLPAGES lines to restore the old values of these parameters. 

6 Adjust system parameters. 

Run the AUTOGEN procedure to adjust system parameters. Enter the 
following command to run AUTOGEN, shut down the system, and reboot 
the system. After updating a common system root on a VAXcluster, run 
AUTOGEN on each node that bootstraps from the common system root. 

$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT 

For more information on the AUTOGEN procedure and the 
MODPARAMS.DAT file, see Section 11 of the VAX/VMS System 
Manager's Reference Manual. 

7 Log in to the system manager's account, SYSTEM. 
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8 Copy VMB.EXE to the console media. 

If you updated a Local Area VAXcluster, you do not need to copy 
VMB.EXE to the console media. 

Otherwise, place a copy of the Version 4.7 VMB.EXE onto each system's 
console media. Note that, if you updated a VAXcluster, you must perform 
this step for each node in the VAXcluster. 

VAX 8530, VAX 8550, VAX 8700, and VAX 8800 Processors 

Perform the following steps to copy VMB.EXE from the system disk to the 
hard disk in the console microcomputer. Perform this entire procedure at 
your system's console terminal — the terminal connected to the console 
microcomputer. 

a. Press CTRL/P to change to console mode. 

b. Place a blank RX50 diskette in diskette drive 1, the top (or left-hand) 
diskette drive. The VAX/VMS operating system refers to diskette 
drive 1 as CSA1; P/OS-DCL refers to diskette drive 1 as DZ1. 

c. Enter the following command at the console-mode prompt (> > >) 
to change to P/OS-DCL mode: 

»> EXIT 

The P/OS-DCL command prompt ($, C, or > ) appears on the 
console terminal. 

d. Enter the following P/OS-DCL command to initialize the diskette, 
substituting any 1- to 12-character name for volume-id: 

$ INITIALIZE DZ1: volume-id 

e. Change to console mode by entering the following P/OS-DCL 
command: 

$ RUN CONTROL 

f. Change to program mode by entering the following console-mode 
command: 

»> SET TERMINAL PROGRAM 

g. Invoke the System Generation Utility (SYSGEN) and connect the 
console by entering the following commands: 

$ RUN SYSSSYSTEM:SYSGEN 
SYSGEN> CONNECT CONSOLE 
SYSGEN> EXIT 

h. Enter the following command to mount the diskette in diskette 
drive 1. 

$ MOUNT /0VERRIDE=ID CSA1: 

i. Create a directory named CONSOLE on the diskette by entering the 
following command: 

$ CREATE /DIRECTORY CSA1:[CONSOLE] 

j. Copy VMB.EXE to the diskette by entering the following command: 

$ COPY SYSSSYSTEM:VMB.EXE CSA1:[CONSOLE] 
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k. Enter the following command to dismount the diskette: 

$ DISMOUNT CSA1: 

l. Change to P/OS-DCL mode by entering the following commands: 

$ |CTRL/P| 

»> EXIT 

The P/OS-DCL prompt ($, C, or > ) appears on the console terminal. 

m. Open the drive door of diskette drive 1, pause for a moment, and 
close the door. The red light will flash and the drive will make a 
whirring sound. 

n. Enter the following P/OS-DCL command to mount the diskette, 
where volume-id is the same 1- to 12-character name you used when 
you initialized the diskette in step d: 

$ MOUNT DZ1: volume-id 

o. Enter the following P/OS-DCL command to copy VMB.EXE from the 
diskette to the fixed disk in the console microcomputer: 

$ COPY DZ1: [CONSOLE]VMB.EXE LBO: [CONSOLE] 

The fixed drive in the console microcomputer is known by two 
names, DW2 and LBO. Most console files are stored using the name 
LBO. If you receive an error message telling you of a protection 
violation on the output device, enter the previous command again, 
substituting DW2 for LBO. 

p. Enter the following P/OS-DCL commands to set your default 
directory to LBO:[CONSOLE] and to ensure that the new VMB.EXE 
appears in that directory: 

$ SET DEFAULT LBO: [CONSOLE] 

$ DIRECTORY VMB.EXE 

q. Change to console mode by entering the following P/OS-DCL 
command: 

$ RUN CONTROL 

r. Change to program mode by entering the following console-mode 
command: 

»> SET TERMINAL PROGRAM 

s. Remove the diskette from the diskette drive. You have successfully 
copied VMB.EXE from the system disk to the hard disk in the console 
microcomputer. 

VAX-11/725, VAX-11/730, and VAX-11/750 Processors 

Perform the following steps to copy the new VMB.EXE from the system 
disk to the console TU58 tape cassette: 

a. Invoke the System Generation Utility (SYSGEN) and connect the 
console by entering the following commands: 

$ RUN SYSSSYSTEM:SYSGEN 
SYSGEN> CONNECT CONSOLE 
SYSGEN> EXIT 

b. Insert the console TU58 in CSA1. 
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c. Back up and restore the console TU58, using the command procedure 
SYS$UPDATE:CONSCOPY.COM described in Section 2.8.1.1 of the 
VAX/VMS System Manager's Reference Manual 

d. Copy VMB.EXE to the console TU58 in CSA1 using the Exchange 
Utility, as follows: 

$ EXCHANGE 

EXCHANGE> COPY/LOG/REPLACE - 

_EXCHANGE> SYS$SYSTEM:VMB.EXE/TRANSFER_MODE=BLOCK CSA1: 

EXCHANGE> EXIT 

e. If your processor is a VAX-11/725 or a VAX-11/730, remove the 
console TU58 from CSA1 and place it in CSA2. 

VAX 8200, VAX 8250, VAX 8300, and VAX 8350 Processors 

Perform the following steps to copy the new VMB.EXE from the system 
disk to the console diskette: 

a. Back up and restore the console diskette, using the command 
procedure SYS$UPDATE:CONSCOPY.COM described in 

Section 2.8.1.1 of the VAX/VMS System Manager's Reference Manual 

b. Invoke the console update command procedure 
SYS$UPDATE:UPDATE_CONSOLE.COM as follows: 

$ @SYS$UPDATE:UPDATE_C0NS0LE 

The UPDATE—CONSOLE command procedure copies the new 
VMB.EXE file onto your console diskette. 

VAX 8600 and VAX 8650 Processors 

To copy the new VMB.EXE from the system disk to the console 
RL02 disk, invoke the console update command procedure 
SYS$UPDATE:UPDATE_CONSOLE.COM as follows: 

$ @SYS$UPDATE:UPDATE_C0NS0LE 

The UPDATE—CONSOLE command procedure copies the new VMB.EXE 
file onto your console RL02 disk. 

VAX-11/780, VAX-11/782, and VAX-11/785 Processors 

To copy the new VMB.EXE from the system disk to the console diskette, 
invoke the console update command procedure SYS$UPDATE:UPDATE_ 
CONSOLE.COM as follows: 

$ @SYS$UPDATE:UPDATE.CONSOLE 

The UPDATE_CONSOLE.COM command procedure uses the Exchange 
Utility to save the contents of your existing console diskette onto disk. 

It then merges the new boot files with the saved copy of your console 
media. Finally, the procedure requests that you insert a scratch medium 
so it can copy the new boot files from disk to a new piece of console 
media. The UPDATE—CONSOLE command procedure does not modify 
your original console media. 

9 Back up the console media. 

Back up your new console media, following instructions in Section 2.8.1.1 
of the VAX/VMS System Manager's Reference Manual 
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Printing Patches Applied by the Update Kit 

If you select option 2 or 3 as an update option (in step 4 of 
Section 1.6), VMSINSTAL produces the update description file, 
SYS$UPDATE:VMS047.TXT. This file lists the patches, new images, and 
miscellaneous fixes that are part of the Version 4.7 update kit. If you print 
this file, you obtain the listing that appears in Appendix A of these release 
notes. 

If you select option 1 or 3, VMSINSTAL produces a journal file (with the 
file type JNL) for each image that is patched during the update. Journal files 
contain a record of each patch made to these images but do not contain 
information about modules that are replaced. Note that no journal files are 
created for tailored systems. 

If you want a listing of the patches produced by the update process, print the 
journal files, using the following steps: 

1 Complete the update procedure that installs Version 4.7, including 
rebooting the system as described in the software installation guide for 
your processor. 

2 Log in to any account that has SYSPRV privilege and enter the following 
command: 

$ PRINT SYS$SYSTEM:*.JNL,SYS$LIBRARY:*.JNL 

The journal files produced by the Version 4.7 update procedure occupy 
approximately 500 blocks. If you must conserve disk space, you can delete 
these files from the system disk after you print them. 



2 New and Changed Features 


This chapter discusses new features added to the VAX/VMS operating system 
since the release of Version 4.6. It also describes features that have changed 
since the release of Version 4.6. Also, because these release notes supersede 
the Version 4.4 through 4.6 release notes, this chapter discusses features that 
have been added to the operating system since Version 4.3. 

For ease of reference, the material in this section is arranged under the 
following categories: 

Section 2.1 - General User Information 
Section 2.2 - System Manager Information 
Section 2.3 - Application Programmer Information 
Section 2.4 - System Programmer Information 

To find specific topics, consult the index in the back of this manual. 


I 2.1 General User Information 

This section describes new VAX/VMS operating system features of interest to 
the general user. It also discusses changes to the operating system. 


2.1.1 Updating a Version 4.6A System Results in Version 4.7A 

When you install the Version 4.7 update on a Version 4.6A system, you 
obtain a Version 4.7A system rather than a Version 4.7 system. All system 
messages, including the message you receive when you bootstrap the system, 
indicate that you are using Version 4.7, however. Use the Patch Utility as 
follows to verify that you are using Version 4.7A. If you receive the message 
%PATCH-I-ECOSET, your system is running Version 4.7A. If you receive the 
message %PATCH-I-ECONOTSET, your system is running Version 4.7. 

$ PATCH/JOURNAL=NL: SYS$SYSTEM:SYS.EXE 
PATCH> CHECK ECO 88 
message appears here 
PATCH> EXIT 

If your system is running Version 4.7A, you can choose to edit the file 
SYS$MANAGER:WELCOME.TXT, to read "Welcome to VAX/VMS 
Version 4.7A". 
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2.1.2 COBOL Run-Time Library Supports the ANSI 1985 COBOL Standard 

The COBOL Run-Time Library and the COBOL compiler handle size error 
conditions differently when no ON SIZE ERROR clause is present. This 
affects how the COBOL Run-Time Library and the COBOL compiler handle 
the divide-by-zero instruction. The COBOL Run-Time Library complies with 
the ANSI 1985 COBOL standard, which states that all programs should 
continue after a divide-by-zero instruction. A program that generates code 
that causes a COBOL Run-Time Library (COBRTL) routine to execute 
a divide-by-zero instruction no longer receives a fatal error and aborts 
execution. Instead, when COBRTL performs a divide-by-zero instruction, 
it signals a nonfatal error indicating a divide-by-zero occurred and program 
execution continues. 

Versions of the VAX COBOL compiler up to and including Version 3.4 
generate a fatal error when they encounter a divide-by-zero instruction. 

A future release of VAX COBOL will conform to the ANSI 1985 COBOL 
standard in all cases where the arithmetic operation is accomplished by 
in-line code. 

A program that generates code that causes a COBRTL routine to execute an 
undefined exponentiation is allowed to continue. Following is an example of 
an undefined exponentiation: 

(- 1)**0 . 5 / 

Further COBRTL support for the ANSI 1985 COBOL standard will be 
implemented in a future release of VAX COBOL. 


2.1.3 VAXTPU Sends Characters to the Terminal Without Translation 

VAXTPU now sends the following additional characters to the terminal 
without translating them into the SUB character: 


%XAO 

%XA4 

%XA6 

%XAC 

%XAD 

%XAE 

%XAF 

%XB4 

%XB8 

%XBE 

%XDO 

%XDE 

%XFO 

%XFE 

%XFF 



2.2 System Manager Information 

This section describes new VAX/VMS operating system features of interest to 
the system manager. It also discusses changes to the operating system. 


2.2.1 New CLUSTER.DAT File 

Starting with Version 4.7, a new system file is maintained in the system root 
of each VAXcluster member. This file is used by the connection manager to 
maintain some configuration-related information when a VAXcluster member 
is rebooted. The file is named [SYSn.SYSEXEJCLUSTER.DAT. 
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2.2.2 New VMB.EXE Image 

VAX/VMS Version 4.7 has a new VMB.EXE image. This image contains 
a new computer interconnect (Cl) boot driver in the PABTDRIVR module. 
This new boot driver corrects intermittent problems writing crash dumps 
over the Cl and improves the reliability of bootstrapping over the CIBCA. 
After updating to Version 4.7, you must update your console media following 
instructions in Section 1.7. 

If your system is part of a Local Area VAXcluster, you do not need to update 
the console media. 


2.2.3 ADD_ Records Allowed in AUTOGEN 

Since Version 4.5, AUTOGEN allows ADD_ records to be included in 
SYS$SYSTEM:MODPARAMS.DAT for all numeric SYSGEN parameters. 
Before Version 4.5, an ADD_ record affected only those parameters that 
AUTOGEN calculated; the amount specified by the record was added to the 
value calculated by AUTOGEN. (See Section 11.4 of the VAX/VMS System 
Manager's Reference Manual.) 

The value specified in an ADD_ record for a parameter that AUTOGEN 
does not calculate is added to that parameter's default value. For 
example, if AUTOGEN encounters the record "ADD_WSINC=50" in 
MODPARAMS.DAT, the value of the WSINC parameter is set to 200 (the 
default value of 150 plus the specified 50) after the next boot. 


2.2.4 DECnet-VAX Logical Link Enhancement 

DECnet-VAX can cache packets received out of order on a given logical link. 
This allows network managers to enable the Equal Cost Path Split feature on 
DECnet Routing implementations that support it. Check the Software Product 
Description (SPD) to see if the Equal Cost Path Split feature is available for 
your DECnet product. 


2.2.5 New Machine Check Handler for VAX 8600/8650 Processors 

Version 4.7 contains a new machine check handler for the VAX 8600 and 
VAX 8650 processors. This new handler enhances the capabilities of the 
previous machine check handler. 


2.2.6 Limited Support for Dual-Pathed HSC Tape Drives 

Since Version 4.6, VAX/VMS has provided limited support for dual-pathed 
hierarchical storage controller (HSC) tape drives. This removes the previous 
restriction against any form of dual-pathed HSC tape drive, and increases 
the usefulness of HSC tape drives in situations where high availability is 
important. 

A dual-pathed HSC tape drive is a drive that is connected to two HSC 
controllers, both of which have the same nonzero tape allocation class. (The 
tape allocation class is set using the HSC console command SET ALLOCATE 
TAPE.) VAX/VMS recognizes the dual-pathed nature of such a tape drive, 
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provided that it has access to both HSC controllers and that both port select 
buttons are depressed on the tape drive. 

For dual-pathed tape drives, VAX/VMS automatically selects a functional 
HSC when processing a MOUNT or INITIALIZE command. However, if the 
selected HSC becomes inoperative while a tape is mounted, the tape must be 
dismounted and remounted in order to cause the alternate HSC to be used. 

Note: This mount-time failover feature should not be confused with automatic 
failover, which can occur without dismounting the unit. VAX/VMS 
provides automatic failover only for disk devices. (See the Guide to 
VAXclusters for a discussion of automatic failover.) 

Note that an HSC that becomes inoperative while I/O is pending is not 
declared inoperative until the timeout period specified by the SYSGEN 
parameter VMSD3 expires. VMSD3 should be set to a nonzero value which 
specifies the number of seconds to wait before attempting to fail over to the 
other port. 

Note also that, due to a problem in the HSC software, a tape subsystem 
that has undergone a failover is declared inoperative by the failing HSC 
when the HSC reboots. To make the tape subsystem operative, you must 
toggle the port select button for the port connected to the failed HSC, or reset 
the tape subsystem. As a result, a tape subsystem cannot, without manual 
intervention, failover to a second HSC and then failover back to the original, 
in the event that the second HSC fails. 


2.2.7 CIBCA — New Device Support 

Since Version 4.6, VAX/VMS has supported the CIBCA. The CIBCA is a two- 
board computer interconnect (Cl) interface for the BI bus and is functionally 
equivalent to the CIBCI. The CIBCA uses the same driver (PADRIVER) and 
device mneumonic (PA:) as the CIBCI, CI750, and CI780. The CIBCA also 
uses the same HSC booting and installation procedures as the CIBCI. 


2.2.8 Backup Utility — RESTART Option 

The following new feature was implemented in Version 4.5. 

If, in the course of writing a save set to tape, the Backup Utility or standalone 
BACKUP encounter bad media or other excessive hardware or media-related 
errors, BACKUP generates the following informational message and prompt: 

7,BACKUP -1 - SPECIFY, specify option (CONTINUE, RESTART, QUIT) 

BACKUP> 

(See the VAX/VMS System Messages and Recovery Procedures Reference Manual 
for a complete description of this message.) 

If the output volume is the first volume in the backup operation, only QUIT 
and CONTINUE are available as valid recovery options. If the output volume 
is a subsequent volume in the BACKUP operation, then RESTART is also 
available. 

RESTART causes BACKUP or standalone BACKUP to restart the backup 
operation at the beginning of the current volume. BACKUP unloads the 
current tape from the drive as soon as the RESTART option is taken and then 
prompts for a replacement volume. It is important that the operator not load 
the new tape until the utility has prompted for it. 
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2.2.9 Limiting Access to Optional Software Products on Clusters 

The following new feature was implemented in Version 4.4. 

It is now possible to limit access to an optional software product to one 
or more nodes in a cluster if the optional software product is placed in a 
common system directory. The method utilizes the access control list (ACL) 
features and a system rights identifier that is created during the startup phase 
of the boot process. 

The identifier created at boot time is SYS$NODE_nodename, where 
nodename is the name defined by the SYSGEN parameter SCSNODE. 
Because each node in the cluster has a unique SCSNODE name, each node 
has a unique identifier. 

Note: An identifier is not created for a node in the cluster if any of the following 
are true: 

1 The SYSGEN parameter SCSNODE is not defined. 

2 The rights list file RIGHTSLIST.DAT is not created in your site- 
specific command procedure (SYS$MANAGER:SYSTARTUP.COM). 
See the Authorize Utility Reference Manual for information about how 
to create this file. 

3 The command LOGOUT is executed from SYSTARTUP.COM. If this 
is the current behavior, the command must be changed to EXIT to 
return control to STARTUP.COM. 

When a user logs in, the node-specific identifier is associated with the process. 
Invoking SHOW PROCESS/PRIVILEGE on NODE1 might yield ^following 
message: 

Process privileges: 

SYSPRV may access objects via system protection 
CMKRNL may change mode to kernel 
OPER operator privilege 

Process rights identifiers: 

SYS$N0DE_N0DE1 

The ACL commands used must limit access to the key images of the chosen 
optional software product. For example, if the product were a language, the 
image that compiles the program would be the file to which access should 
be restricted. The SET FILE/ACL=(IDENTIFIER) command is used to create 
the access control list for the file specified; entering a SHOW ACL command 
displays the access control list. 

It should be mentioned that not all files on an optional software product need 
to be restricted. 
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The following example shows the necessary commands for limiting node 
access to an optional software product: 

$! Allow access to the FORTRAN compiler on N0DE1 in the cluster. 

$! 

$ SET FILE/ACL=(IDENTIFIER=*, ACCESS=NONE) SYS$SYSTEM:FORTRAN.EXE 
$ SET FILE/ACL=(IDENTIFIER=SYS$N0DE_N0DE1. ACCESS=EXECUTE) SYS$SYSTEM:FORTRAN.EXE 
$! 

$! NOTE: The first SET FILE/ACL command specifies that no one has access 
$! to the FORTRAN image. The second command specifies that only processes 

$! with the identifier SYS$N0DE_N0DE1 can access the image. Thus, 

$! only those users who can log into N0DE1 may use FORTRAN. 

$! Limit access to the other key FORTRAN images. 

$! 

$ SET FILE/ACL=(IDENTIFIER=*, ACCESS=NONE) SYS$MESSAGE:F0RTERR1.EXE 

$ SET FILE/ACL=(IDENTIFIER=SYS$N0DE_N0DE1, ACCESS=EXECUTE) SYSSMESSAGE:F0RTERR1.EXE 

$ SET FILE/ACL= (IDENTIFIERS, ACCESS=NONE) SYS$MESSAGE:F0RTERR2.EXE 

$ SET FILE/ACL=(IDENTIFIER=SYS$N0DE_N0DE1, ACCESS=EXECUTE) SYS$MESSAGE:F0RTERR2.EXE 

$! 

$! Show the access control list for the FORTRAN compiler. 

$! 

$ SHOW ACL SYSSSYSTEM:FORTRAN.EXE 
$! 

Object type: file, Object name: DISK$:[SYSEXE]FORTRAN.EXE;1, 
on 01-01-1985 10:00:00.00 

(IDENTIFIER=SYS$N0DE_N0DE1,ACCESS=EXECUTE) 

(IDENTIFIERS, ACCESS=NONE) 

$! 

$! 

$! Allow access to the optional software product BASIC for two nodes in the cluster. 

$1 

$ SET FILE/ACL=(IDENTIFIER=*) SYS$SYSTEM:BASIC.EXE 

$ SET FILE/ACL=(IDENTIFIER=SYS$N0DE_N0DE1, ACCESS=EXECUTE) SYS$SYSTEM:BASIC.EXE 
$ SET FILE/ACL= (IDENTIFIERS) SYSSMESSAGE:BASICMSG.EXE 

$ SET FILE/ACL=(IDENTIFIER=SYS$N0DE_N0DE2, ACCESS=EXECUTE) SYSSMESSAGE:BASICMSG.EXE 

Table 2-1 shows various optional software products and their associated key 
image file names. 


Table 2-1 Optional Software Products to Which Access Can Be 
Restricted 


Optional 

Software 

Product 

Key Image File Name 

VAX Ada 

SYSSSYSTEM: ADA. EXE 

SYSSSYSTEM: AD ASFROM_CDD.EXE 
SYS$SYSTEM:ADA$STAT.EXE 

VAX APL 

SYS$SYSTEM:APL.EXE 

SYS$LIBRARY: APLTAP.EXE 

SYSSMESSAGE: APLMSG.EXE 

VAX BASIC 

SYSSSYSTEM: BASIC. EXE 

SYS$SYSTEM:B ASICMSG.EXE 

VAX BLISS-16 

SYS$SYSTEM:BLISS16.EXE 

VAX BLISS-32 

SYS$SYSTEM:BLISS32.EXE 
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Table 2—1 (Cont.) Optional Software Products to Which Access Can 



Be Restricted 

Optional 

Software 

Product 

Key Image File Name 

VAX C 

SYSSSYSTEM: VAXC.EXE 

SYS$MESS AGE: VAXCCRXERR.EXE 

SYS$MESS AGE: VAXCERR.EXE 

SYS$MESSAGE: VAXCVCGERR.EXE 

VAX CDD 

SYS$SYSTEM:CDDL.EXE 

SYS$SYSTEM:CDDV.EXE 

SYS$SYSTEM:DMU.EXE 

SYS$MESSAGE:CDDEXC.EXE 

SYS$MESSAGE:CDDVEXC.EXE 

SYS$MESSAGE:CDDLEXC.EXE 

SYS$MESSAGE:DMUEXC.EXE 

VAX COBOL 

SYS$SYSTEM:COBOL.EXE 

SYS$SYSTEM:C0B11T.EXE 

VAX DIBOL 

SYS$SYSTEM:DIBOL83.EXE 

SYS$MESSAGE:DIBOL83MSG.EXE 

SYS$MESSAGE:DBLRTLMSG.EXE 

SYS$SYSTEM:DBLSORT.EXE 

SYS$SYSTEM:DBLS0RT2.EXE 

SYS$SYSTEM:DBLSTATUS.EXE 

SYS$SYSTEM:DBLMSGMGR.EXE 

SYS$SYSTEM:DBLISMUTL.EXE 

SYS$LIBRARY:DBLRTL.EXE 

VAX DSM 

SYS$SYSTEM:DSM.EXE 

SYS$MESSAGE:DSMJRN.EXE 

SYS$MESSAGE:DSMMJC.EXE 

VAX FORTRAN 

SYS$SYSTEM:FORTRAN.EXE 

SYS$MESSAGE:FORTERR 1 .EXE 
SYS$MESSAGE:F0RTERR2.EXE 

VAX LISP 

SYS$COMMON:[VAXLIS]LISP.EXE 

VAX LSE 

SYS$SYSTEM:LSEDIT.EXE 

SYS$MESSAGE:LSEMSG.EXE 

SYS$LIBRARY:LSESHR.EXE 

VAX PASCAL 

SYS$SYSTEM:PASCAL.EXE 

SYS$MESSAGE:PASCALER1 EXE 

SYS$MESSAGE:PASC ALER2.EXE 

VAX PL/I 

SYS$SYSTEM:PLIG.EXE 

SYS$MESSAGE:PLIGERR1 .EXE 
SYS$MESSAGE:PLIGERR2.EXE 
SYS$MESSAGE:PLIGERR3.EXE 

VAX RPG II 

SYS$SYSTEM:RPG.EXE 
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2.2.10 SYSGEN Command CONNECT CONSOLE — New Qualifier 

In Version 4.4, the /REMOTE qualifier was added to the SYSGEN command 
CONNECT CONSOLE. This qualifier enables a remote diagnostic port for a 
second console or terminal connected to a VAX 8600 or a VAX 8650 processor. 


2.2.11 Mount Utility — New Option 

The following new feature was implemented in Version 4.4. 

The MOUNT command /CACHE=option qualifier has a new option, 

TAPE _DATA. The /CACHE=TAPE_DATA qualifier enables the write cache 
for a tape device if the tape controller supports a write cache. /NOCACHE 
is the default for mounting on tape devices. If the tape controller does not 
support a write cache, the option is ignored. 

Note that the other options for the /CACHE=option qualifier pertain only to 
disks, while the TAPE—DATA option is used only with magnetic tapes. The 
following command mounts the volume TAPE on device MUAO and instructs 
MOUNT to enable the tape controller's write cache for MUAO: 

$ MOUNT/CACHE=TAPE_DATA MUAO: TAPE 

7,MOUNT-I-MOUNTED, TAPE mounted on _N0DE$MUA0: 


2.3 Application Programmer Information 

This section describes new VAX/VMS operating system features of interest 
to the application programmer. It also discusses changes to the operating 
system. 


2.3.1 Linking Workstation Applications on Non-Workstation Machines 

The UISSHR.EXE executable image allows you to link workstation 
applications on non-workstation machines. Version 4.7 of VAX/VMS updates 
the UISSHR.EXE image to include all UIS calls supported in Version 3.2 of 
the MicroVMS workstation software. 


2.3.2 Debugger — Changes for VAXstations 

Prior to Version 4.6, if the debugger was invoked on a VAXstation, it 
created a separate emulated terminal window for debugger input and output. 
Thus, terminal I/O performed by the program was logically and physically 
separated from debugger I/O. This behavior is especially useful for debugging 
screen-oriented applications. 

To eliminate a potential problem, the method the Version 4.6 (and later 
versions) debugger uses to control the separate window has been changed. 
Previously, the debugger controlled the separate window with UIS$xxx calls. 
The debugger now uses the new operating system command (OSC) sequences 
to communicate control functions to the terminal emulator. As a result, the 
debugger's behavior is slightly different for Version 4.6 and later versions. 
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The debugger still creates a separate window but only if both of the 
following conditions are met: 

• You must be running VWS V3.0 (or higher). 

• You must have the following system logical name defined: 

$ DEFINE/SYSTEM/EXEC UIS$VT_ENABLE_OSC_STRINGS TRUE 


2.3.3 Linker Utility — Debugging Shareable Images 

The following new feature was implemented in Version 4.4. 

You can now link a shareable image by entering the following command: 

$ LINK/SHAREABLE/DEBUG image-name,... 

The qualifiers /[NO]TRACEBACK and /DEBUG are processed for a shareable 
image exactly as they are for an executable image. Previously, the /DEBUG 
qualifier was prohibited and the /[NOJTRACEBACK qualifier ignored when 
linking a shareable image. 


2.3.4 Terminal Driver Support — Changes 

The following changes were made to VAX/VMS terminal support in 
Version 4.4. 



2.3.4.1 

SET HOST/DTE Can Generate a Break 

In order to log in on lines that expect a break rather than carriage return, you 
can now generate a break in SET HOST/DTE by simultaneously pressing the 
CTRL and Right Bracket (]) keys (CTRL/]). 

•> 

2.3.4.2 

SET HOST/DTE/DIAL Command — Problem and Solution 

The SET HOST/DTE/DIAL command does not work with the DMF-32 
controller because the modem sends a response character to the host when it 
detects a carrier signal. The DMF-32 controller drops any input until it sees 
the carrier signal. 

One solution is to modify the example autodialer provided in 
SYS$EXAMPLES:DT_DF03.MAR to perform a IO$_SENSEMODE!IO$M_ 
RD—MODEM $QIO to check for a carrier signal. If set, the autodialer should 
assume success and continue. 


2.3.4.3 

Disabling Automatic Hangup 


In Version 4.0, lines with the MODEM characteristic would hang up 30 
seconds after sensing a CARRIER signal if a channel was not assigned to 
the device. This feature was implemented as a security feature to prevent 
unused lines from being tied up. It is now possible to disable this hangup on 
a systemwide basis by setting the bit-2 value to 4 in the SYSGEN parameter 
TTY—DIALTYP. 


2.4 System Programmer Information 

This section describes new VAX/VMS operating system features of interest to 
the system programmer. It also discusses changes to the operating system. 
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2.4.1 Cl Port Driver (PADRIVER) 

The following sections contain information about the computer interconnect 
(Cl) port driver, PADRIVER. 


2.4.1.1 Supported Microcode 

If you have not done so already, you should upgrade to Version 7.0 of the 
CI-780 microcode as soon as possible. You can identify the current microcode 
version by following these steps: 

1 Enter the following command: 

$ SHOW CLUSTER/CONTINUOUS 

2 Enter the ADD RP_REVIS subcommand, as follows: 


C0MMAND> ADD RP.REVIS 

The low-order word is the random access memory (RAM) version and 
the high-order word is the programmable read-only memory (PROM) 
version. For Version 7.0 microcode, this field contains 70007 16 . 

The port driver displays the following message for sites containing old 
versions of the microcode: 

# /«PAA0, - Cl port ucode not at current rev level. PROM/RAM rev is 0005/0003 

3 Enter the following command to return to DCL command level: 
C0MMAND> EXIT 


2.4.1.2 Variable Cl Port Sanity Timer 

Version 7.0 of the Cl microcode contains a variable sanity timer. When this 
sanity timer expires, the following error message appears on the operator's 
console. The message shows that the Port Status Register (PSR) has a value 
of 40 16 . 

# / 0 PAAO, - Port Error Bit(s) Set - CNF/PMC/PSR xxxxxxxx/xxxxxxxx/00000040 r 

The appearance of this error and other Cl-related timeout errors does not 
necessarily mean that the Cl hardware is bad. The system could be spending 
a long time at high hardware priority levels. This long latency could result 
from the setting of the SYSGEN parameters, the nature of the processing load 
on the cluster, or the presence of user-written privileged code. 

You should first increase the value of the PASTIMOUT parameter until these 
errors occur infrequently, if at all. You may then wish to consult the Guide 
to VAX/VMS Performance Management to investigate the general performance 
characteristics of your system. 
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2.4.1.3 System Communication Services Virtual Circuit Timeouts 

The VAX/VMS Version 4.4 and subsequent versions of the Cl port driver and 
the Version 7.0 Cl microcode implement a system communication services 
(SCS) virtual circuit timeout. This mechanism reduces cluster transition times 
by allowing rapid detection of a failed cluster node. In VAX/VMS 
Version 4.3, certain catastrophic hardware failures prevented orderly 
shutdown of the failing node. Because such failures did not shut down 
the Cl port, other cluster members did not recognize a hardware failure for at 
least 100 seconds. This period is the expiration time for the sanity timer of 
the Cl port. 

The SCS virtual circuit timeout reduces the cluster transition time by requiring 
that CPUs, not ports, exchange periodic SCS control messages. The failure of 
a node to respond to an SCS control message within a specified time causes 
the port driver to break the virtual circuit and notify the connection manager 
of a communication problem. 

With this timeout mechanism enabled, the Cl port driver periodically checks 
to see that it is receiving systems-level messages from all remote VAX/VMS 
processors. The presence of these messages guarantees that the remote 
processor is not halted or hung in a loop at hardware IPL 7 or greater. If no 
routine messages appear from a remote node, the Cl port driver attempts to 
generate traffic by sending a dummy keep-alive message to the remote node. 


2.4.1.4 Virtual Circuit Timeout Errors 

A timeout of the keep-alive message destroys the logical link between the two 
systems. When a timeout occurs, the driver closes the logical link, creates an 
error log entry, and prints the following message on the operator's console: 

°/oPAAO, Virtual Circuit Timeout - REMOTE PORT nn 

These messages do not represent a hardware failure but they do notify the 
system manager that the remote node is either halted or spending a long 
time at high hardware priority levels. Occurrence of the latter depends on 
the setting of the SYSGEN parameters, the nature of the processing load 
on the cluster, and on the presence of user-written privileged code. The 
system manager should first increase the PASTIMOUT timeout parameter 
(described below) until virtual circuit timeouts occur infrequently if at all. The 
system manager may then wish to consult the Guide to VAX/VMS Performance 
Management to investigate the general performance characteristics of the 
system. 
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2.4.1.5 SYSGEN Parameters 

The following SYSGEN parameters affect the SCS virtual circuit timeout 
mechanism. The system manager must ensure that these parameters are the 
same on all nodes in a cluster. 


Parameter Name Meaning 

PASANITY This is a boolean parameter which, when set to zero, 

disables the timeout mechanism. This parameter is used 
for the debugging of system code and should not be 
changed. (Default is 1.) 

Customers writing privileged code using the XDELTA 
debugging tool must set PASANITY to zero on the entire 
cluster to avoid a CLUEXIT bugcheck. 

PASTIMOUT The activation time for the port timeout mechanism of the 

port driver. The port driver is able to detect a virtual circuit 
timeout within a minimum of PASTIMOUT seconds and a 
maximum of 3K PASTIMOUT seconds. 

The driver adjusts the effective value of PASTIMOUT if 
the PAPOLLINTERVAL parameter is too low. The effective 
value of PASTIMOUT is computed as follows (assuming 
PAPOLLINTERVAL is less than or equal to PASTIMOUT): 

Effective PASTIMOUT = 
MAX(PASTIMOUT,2*PAPOLLINTERVAL) 

Do not set PAPOLLINTERVAL greater than PASTIMOUT. 
Such a setting has no useful purpose. (Default is 5 
seconds.) 

PAPOLLINTERVAL This parameter specifies the duration for which the Cl port 
driver requests the port to poll for other nodes in a cluster. 
The failure of the port to complete a poll during this interval 
causes the driver to declare a Cl port timeout and reset the 
port. 

The port driver must guarantee detection of a failed local 
port before detection of failed links to remote nodes. 
Otherwise, a port failure could result in multiple "virtual 
circuit timeout" messages for every remote node. The 
port driver uses the formula included in the description of 
the PASTIMOUT parameter to ensure that a port timeout 
precedes virtual circuit timeouts. (Default is 5 seconds.) 
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Parameter Name Meaning 


RECNXINTERVAL This parameter specifies the amount of time that the 
connection manager waits between the loss of a 
connection to a remote node and the initiation of a 
cluster transition to remove the failed node from the 
cluster. The minimum value of RECNXINTERVAL must 
guarantee that all of the connections seen from the 
viewpoint of the remote node are broken. Otherwise, 
the remote node may continue to access cluster disks 
after being removed from the cluster. The correct setting 
of RECNXINTERVAL is at least three times the effective 
value of PASTIMOUT, as determined by the following 
formula (assuming PAPOLLINTERVAL is less than or equal 
to PASTIMOUT): 

RECNXINTERVAL > 

3*(MAX(PASTIMOUT,2*PAPOLLINTERVAL)) 

Since the default intervals for PASTIMOUT and 
PAPOLLINTERVAL are 5 seconds, the minimum allowable 
RECNXINTERVAL is 30 seconds. The default is 60 
seconds. 


For clusters requiring rapid failover, the system manager can decrease both 
PASTIMOUT and PAPOLLINTERVAL to 1 second. On heavily loaded 
clusters, however, this rapid failover may lead to an increase of CLUEXIT 
bugchecks on individual nodes. Clusters with Version 5.0 Cl microcode 
should retain the default settings, since the port driver does not enable the 
virtual circuit sanity timer. 

System Communication Timeout SYSGEN Parameters 


Parameter 

Default 

Minimum 

PASANITY 

1 sec 

1 sec 

PAPOLLINTERVAL 

5 sec 

1 sec 

PASTIMOUT 

5 sec 

1 sec 

RECNXINTERVAL 

60 sec 

6 sec 


Result 

Default 

Minimum 

Port failure 

detection 

5-10 sec 

1-2 sec 

Virtual Circuit 
failure detection 

10-30 sec 

2-6 sec 
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Corrected Problems, Restrictions, and Notes 



This chapter discusses problems that have been corrected in Version 4.7 of the 
VAX/VMS operating system. It also describes any restrictions that may apply 
to the use of the Version 4.7 operating system and contains other information 
concerning the release. 

For ease of reference, the material in this section is arranged under the 
following categories: 

Section 3.1 - General User Information 

Section 3.2 - System Manager Information 

Section 3.3 - Application Programmer Information 

Section 3.4 - System Programmer Information 

To find specific topics, consult the index in the back of this manual. 

3.1 

General User Information 

This section describes problems resolved in VAX/VMS Version 4.7, lists 
known restrictions, and contains other information of interest to the general 
user. 

3.1.1 

Command Procedures — Change for Next Major Release 

In the next major release of the VAX/VMS operating system, all commands, 
full-line comments, and labels in command procedures must be preceded by a 
dollar sign ($). Although users have always been instructed to place a dollar 
sign before commands and labels, command procedures that omit dollar signs 
before labels have not necessarily stopped executing. The next major release 
of the VAX/VMS operating system, however, will treat labels with missing 
dollar signs as data lines. Any reference to a label with a missing dollar sign 
will not execute as expected. 

3.1.2 

SET HOST/HSC/LOG='filename' Command — Problem Fixed 

VAX/VMS Version 4.7 corrects a problem with the DCL command 

SET HOST/HSC/LOG-filename'. This problem, which was introduced 
in Version 4.6, caused the SET HOST/HSC/LOG='file-name' command 
to ignore a user-supplied file name and to always use the default name 
HSCPAD.LOG to name the log file. The command now works correctly and 
names the log file HSCPAD.LOG if no file name is specified or 'file-name' if 
a file name is specified. 
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3.1.3 The SUBMIT Command Ignores the /CLI Qualifier — Problem 

The /CLI qualifier to the SUBMIT command fails to invoke the specified 
command language interpreter when the batch job is run. Instead, the 
command language interpreter specified in the User Authorization File (UAF) 
for the owner of the job is used (as if the /CLI qualifier were not present). 


3.1.4 Unsynchronized Cluster Time Affects SUBMIT/AFTER Command 

In a VAXcluster, a batch job submitted to execute at a specified time 
may begin execution a little before or after the requested time. This 
occurs when the clocks of the member systems in the VAXcluster are not 
synchronized. For example, a job submitted using the DCL command 
SUBMIT/AFTER=TOMORROW may execute at 23:58 relative to the host 
system's clock. 

This problem can occur in a cluster even if a job is run on the same machine 
from which it was submitted, because the redundancy built into the 
batch/print system allows more than one job controller in the cluster to 
receive a timer AST for the job and, thus, to schedule it for execution. 
Moreover, this behavior is exacerbated if the batch job immediately resubmits 
itself to run the next day using the same SUBMIT command. This can result 
in having multiple instances of the job executing simultaneously because 
TOMORROW (after midnight) may be only a minute or two in the future. 

A workaround to this problem is to place the SUBMIT command in a 
command procedure that begins with a WAIT command, where the delta¬ 
time specified in the WAIT command is greater than the maximum difference 
in time between any two systems in the cluster. Use the SHOW TIME 
command on each system to determine this difference in time. 


3.1.5 Extended File Names or File Types — Caution 

Although file names and file types of up to 39 characters are permitted 
starting with VAX/VMS Version 4.0, for some files you may need to use the 
VAX/VMS Version 3.x maximum lengths (9 characters for the file name and 
3 characters for the file type), or other maximum lengths as appropriate. 

For example, you must use restraint in naming files that will be accessed by: 

• Operating systems that cannot support longer file names and file 
types, such as VAX/VMS Version 3.x systems and systems for PDP-11 
processors 

• Applications software that does not accept longer file names and file types 

Be careful when you are naming files that will be copied or accessed by 
remote systems. The file-naming abilities of VAX/VMS after Version 4.0 
exceed those of most other computer systems, including VAX systems running 
VAX/VMS Version 3.x. For example, a system running VAX/VMS 
Version 3.x returns a syntax error when a file specification contains a file 
name (including a directory name) longer than 9 characters, a file type 
longer than 3 characters, a dollar sign ($), or an underscore (_). Valid file 
specifications of VAX/VMS after Version 4.0 that are invalid on a VAX/VMS 
Version 3.x system include the following: 
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% 3 - 1 - 6 


3.1.7 


NODE::DBA2:[YOUR.DIR]FILE.DAT 
NODE::DBA2:[DIRjFILET00L0NG.DAT 
NODE::DBA2:[DIR]FILE.TEST.DAT 
NODE::DBA2:[DIR]FILE.DATA 

A user of a Version 4.0, or later, system would have to rename these files 
before the remote system could access them. Alternatively, the user could 
copy these files to the remote system by using valid VAX/VMS Version 3.0 
output file specifications. 

File name restrictions are generally determined by the file name capabilities 
of the remote systems that require access to the file. Such restrictions should 
be considered as part of the overall application design when network access 
is required. 

Applications that parse file specifications using the pre-Version 4.0 file 
specification conventions should be modified to use the services or routines 
that can parse or scan file specifications using the new extended file 
specifications conventions. These services and routines include the RMS 
Parse service and the Scan String for File Specification system service (see the 
VAX Record Management Services Reference Manual and the VAX/VMS System 
Services Reference Manual) and the LIB$FIND_FILE and LIB$FILE_SCAN 
routines (see the VAX/VMS Run-Time Library Routines Reference Manual). 


Shutdown Notification on Clusters — Note 

When the REMOVE—NODE option is specified during execution of an orderly 
shutdown procedure (SYS$SYSTEM:SHUTDOWN.COM) on one VAXcluster 
member system, users on all member systems are notified. Clusterwide 
notification is required, because users logged in to any member system may 
be affected by the shutdown of another system in various ways: 

• Users may have batch jobs running on other systems. 

• If terminal servers are in operation, users may have alternate terminal 
sessions in progress (for example, an editing session) on the system being 
shut down. 

Since shutdown messages include the name of the member system being shut 
down, users need only check the messages carefully to avoid logging out of a 
system unnecessarily. 

Note that, for those reasons, clusterwide notification is not affected by the 
shutdown procedure's REPLY/NODE= option. If, for some reason, you wish 
to limit shutdown notification to specific member systems, define the logical 
name SHUTDOWN$INFORM_NODES before executing the shutdown 
procedure. For example: 

$ DEFINE SHUTDOWNSINFORM.NODES MOE,LARRY 
$ OSYSSSYSTEM:SHUTDOWN 

In this example, only users on systems MOE and LARRY will be notified. 


TK50 Tape Drive — Problem Fixed 

Before Version 4.7, the TK50 tape drive would hang the user process if the 
tape cartridge from which it was trying to read data had fewer than four file- 
header records. This problem has been fixed. The TK50 tape drive can read 
data from a TK50 tape cartridge that contains only two file-header records. 
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3.1.8 Physical QIOs to a DSA Tape Device Might Result in a Fatal Error 

When physical I/O functions are issued to DSA tape devices, the tape class 
driver (TUDRIVER) might return the following error message: 

y,SYSTEM-F-VOLINV, volume not software enabled 

This is usually caused by physical I/O functions being issued while other I/O 
operations are outstanding to the tape controller. (DIGITAL-supplied utilities 
should not encounter this problem.) 

To avoid this problem, you can substitute the IO$_READLBLK and IO$— 
WRITELBLK function codes for the IO$_READPBLK and IO$_WRITEPBLK 
function codes. The IO$_READLBLK and IO$_WRITELBLK function codes 
are functionally equivalent to the IO$_READPBLK and IO$_WRITEPBLK for 
DSA tape devices. 

This problem exists in VAX/VMS Versions 4.6 and 4.7. In VAX/VMS 
Version 4.5 and earlier versions, physical I/O operations completed correctly 
when other I/O operations were outstanding to the tape controller. This 
problem will be fixed in a future release of the VAX/VMS operating system. 


3.1.9 Tape Class Driver (TUDRIVER.EXE) — Problem Fixed 

VAX/VMS Version 4.7 contains a patch to the tape class driver 
(TUDRIVER.EXE) to fix the following problem. 

Issuing an IO$_REWIND QIO with the IO$M_NOWAIT modifier set to a 
TU81 or TU81-Plus, followed immediately by an IO$_REWINDOFF or 
IO$_UNLOAD QIO, may cause the process to hang. This sequence of QIOs 
occurs when a DISMOUNT command is issued immediately after a file on 
tape is closed. The TU81 and TU81-Plus magnetic tape drives cannot process 
this command sequence properly. 

When this sequence of events occurs, the tape class driver reinitializes 
the tape controller, but the tape class driver does not recover from the 
reinitialization properly. This improper reinitialization recovery leaves the 
IO$_REWINDOFF or IO$_UNLOAD QIO in the I/O pending queue. The 
process hangs waiting for this I/O to complete. The Version 4.7 patch to the 
tape class driver (TUDRIVER.EXE) retries the I/O rather than leaving it in the 
pending queue. 

A future version of the TU81 and TU81-Plus microcode will handle this 
command sequence properly, eliminating the necessity for the tape class 
driver to reinitialize the controller. 


3.1.10 ANALYZE/ERROR—LOG Command — Problem 

The ANALYZE/ERROR—LOG command of the Error Log Utility now 
recognizes TA79 tape drive error log entries. When the command processes 
the extended drive status information, it identifies the TA79 device incorrectly 
as a TA78 device. 

DIGITAL expects to fix this problem in a future release of VAX/VMS. 
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3.1.11 

Invalid Access Control List Error Message Fixed 


Before Version 4.7, a file protection operation sometimes returned the 
incorrect error status SS$_IVACL. The protection operation returned this 
status if the file affected by the protection operation had multiple file headers 
with large access control lists within each file header. This problem was 
usually seen on disks with very fragmented files. Version 4.7 fixes this 
problem. 


3.1.12 SET FILE/ACL Command and Search Lists — Problem Fixed 



Before Version 4.7, if a search list specifying multiple devices was used as a 
part of the target file specification in the SET FILE/ACL command, the SET 
FILE/ACL command always attempted to modify the file on the first device 
in the search list. Version 4.7 fixes this search list translation problem. The 
SET FILE/ACL command, when used in conjunction with search lists, now 
modifies the access control list on the file located on the correct device. 

3.2 

System Manager Information 

This section describes problems resolved in VAX/VMS Version 4.7, lists 
known restrictions, and contains other information of interest to the system 
manager. 

3.2.1 

MicroVMS Workstation Software (VWS) Compatibility 

VAX/VMS Version 4.7 is compatible with all versions of the MicroVMS 
Workstation Software (VWS) through VWS Version 3.2. 

3.2.2 

VAX RMS Journaling Version 1.0 Operates Correctly with VAX/VMS 
Version 4.7 

The VAX RMS Journaling Installation Guide and Release Notes states that 
VAX/VMS Version 4.6 or MicroVMS Version 4.6 must be running on your 
system in order to install VAX RMS Journaling, Version 1.0. You can also 
install VAX RMS Journaling on a system that is running VAX/VMS 

Version 4.7 or MicroVMS Version 4.7. 

If you installed VAX RMS Journaling on a system running VAX/VMS 

Version 4.6 or MicroVMS Version 4.6, there is no need to reinstall 

VAX RMS Journaling after updating to VAX/VMS Version 4.6 or MicroVMS 
Version 4.6. 
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3.2.3 Defining a Logical Name for a Disk when Using VAX RMS Journaling 

Information about defining logical names was documented incompletely in 
Chapters 4 and 6 of the VAX RMS Journaling Manual , Version 1.0. (The 
/TRANSLATION=TERMINAL qualifier to the DEFINE command was 
omitted.) These chapters should contain the following information. 

RMS attempts to translate the executive-mode logical name DISK$volume_ 
label when creating or accessing an after-image, before-image, or recovery 
unit journal file. This is the default logical name created by the Mount Utility 
only if no other logical name was specified when the disk is mounted. Thus, 
if the disk was mounted with the following command, the logical name 
DISK$FINANCE_DISK is created: 

$ MOUNT/SYSTEM DBAO: FINANCE.DISK 

Suppose, however, that the disk was mounted using the following command, 
which defines the logical name DISKI: 

$ MOUNT/SYSTEM DBAO: FINANCE.DISK DISKI 

In this case, you must explicitly define the logical name DISK$FINANCE_ 
DISK as follows: 

$ DEFINE/SYSTEM/EXECUTIVE_MODE/TRANSLATION=TERMINAL - 
_$ DISK$FINANCE_DISK DBAO: 

If you fail to explicitly define the logical name for the disk, VAX RMS 
Journaling cannot open journal files on the disk. The following error message 
results if VAX RMS Journaling cannot open a recovery unit journal file: 

# /,RMS-F-ACC_RUJ, recovery unit journal can not be accessed 

The following error messages result if VAX RMS Journaling cannot open 
after-image journal files: 

# /,RMS-F-ACC_AIJ, after image journal cannot be accessed 
-SYSTEM-F-NOLOGNAM, no logical name match 

The following error messages result if VAX RMS Journaling cannot open 
before-image journal files: 

'/,RMS-F-ACC_BIJ, before image journal cannot be accessed 
-SYSTEM-F-NOLOGNAM, no logical name match 


3.2.4 Modem Signal Requirements Will be Enforced — Planned Change 

In a future major release of the VAX/VMS operating system, the modem 
signal requirements described in Section 8.2.3 of the VAX/VMS I/O User's 
Reference Manual: Part I will be enforced. System managers should be sure 
that their host system modems are wired properly and meet the requirements. 
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3.2.5 DUP11 Synchronous Communication Line Adapter Support 

In the next major release of the VAX/VMS operating system, support for 
the DUP11 synchronous communication line adapter will be withdrawn. 
XWDRIVER, the device driver for the DUP11, will be removed from the kit 
at that time. VAX PSI, VAX 3271, and VAX 2780/3780 customers will not be 
affected by the withdrawal of VAX/VMS support, as drivers which support 
both the IBM bisynchronous and the HDLC protocols are provided with those 
products. 


3.2^6 User Environment Test Program (UETP) — Problems and Solutions 

The User Environment Test Program (UETP) is a VAX/VMS software package 
designed to test whether the operating system is installed correctly. The 
following sections describe problems with UETP. 


3.2.6.1 Cluster Test Phase — Problem and Solution 

The Version 4.7 update procedure requires you to either supply a password 
for the SYSTEST—CLIG account or to disable this account. The Cluster Test 
Phase of UETP uses the SYSTEST_CLIG account to create test processes 
on each node within the cluster. This phase of UETP assumes that the 
SYSTEST_CLIG account has no password and that the account is enabled. 
Therefore, if you run UETP in a cluster environment after supplying a 
password for SYSTEST_CLIG or disabling this account, you receive the 
following error message for each node being tested: 

# /oSYSTEM-F-INVLOGIN, login information invalid at remote node 

If you disabled the account during the update procedure, use the Authorize 
Utility to reenable the account, as follows: 

$ SET DEFAULT SYS$SYSTEM 
$ RUN AUTHORIZE 

UAF> MODIFY /FLAGS=NODISUSER SYSTEST.CLIG 
UAF> EXIT 
$ 

If you changed the password to the SYSTEST_CLIG account during the 
update procedure, use the Authorize Utility to change the password for the 
SYSTEST_CLIG account to the null password, as follows: 

$ SET DEFAULT SYS$SYSTEM 
$ RUN AUTHORIZE 

UAF> MODIFY /NOPASSWORD SYSTEST.CLIG 
UAF> EXIT 

$ 

Note: DIGITAL recommends that you disable the SYSTEST—CLIG account after 
testing has been completed. 


t 
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3.2.6.2 Cluster Test Phase Failures 

The UETP cluster test phase might fail while communicating with cooperating 
test nodes through DECnet when the test nodes exist in a large Local Area 
VAXcluster configuration. The probability of these failures increases if activity 
is high on the test nodes. 

Failures occur most often during the startup of the test and at the end of the 
test (during attempts to retrieve error log information). 

A future release of the operating system will improve the performance of the 
test on large Local Area VAXcluster configurations. Until this improvement is 
made, DIGITAL recommends that you restrict cluster activity to a minimum 
during testing. 


3.2.6.3 FILLM Quota Problems 

UETP may fail if the FILLM quota of the SYSTEST account is too low. 

The following sections describe values for FILLM that are required to run 
UETP. If both situations described in the following sections apply to your 
configuration, calculate FILLM for both situations and increase FILLM to the 
larger of the two values. 


3.2.6.3.1 Testing Large Local Area VAXclusters — Problem 

If your Local Area VAXcluster configuration has more than 18 nodes, the 
cluster test phase of UETP outputs an exceeded quota error message during 
the test set up. This problem is a result of an inadequate value for the FILLM 
quota of the SYSTEST account. (By default, FILLM is 20.) 

If you are testing Local Area VAXcluster configurations with more than 18 
nodes, DIGITAL recommends increasing FILLM to a value that is 2 greater 
than the total number of nodes in your cluster. For example, if your cluster 
has 20 nodes, increase FILLM to 22. Section 3.2.6.3.2 describes how to 
increase the FILLM quota. 

This problem will be corrected in the next major release of the operating 
system. 


3.2.6.3.2 Error in UETDISKOO Test Image — Problem and Solution 

When the UETDISKOO test image tests 10 or more disks connected to a single 
controller, the following fatal error may result: 

********************** 

* DISK_NODE$DUA * 

* Error count = n * 

********************** 

-UETP-E-TEXT, RMS file error in file NODE$DUAxx:N0DE$DUAxx.TST 
-RMS-E-CRE, ACP file create failed 
-SYSTEM-F-EXQUOTA, exceeded quota 

If you receive this error message, you must increase the open file limit 
(FILLM) quota for the SYSTEST account. First, determine which disk 
controller has the greatest number of disks attached to it. The new value 
for FILLM should be 5 more than twice the number of disks attached to this 
controller. For example, if there are 12 disks attached to the disk controller 
with the most disks, calculate the FILLM as follows: 

FILLM = (2 * 12) + 5 
FILLM = 29 
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Follow these steps to increase the value of FILLM for the SYSTEST account: 

1 Log in to an account with SYSPRV privilege. 

2 Enter the following commands to invoke the Authorize Utility: 

$ SET DEF SYSSSYSTEM 
$ RUN AUTHORIZE 
UAF> 

3 Enter the following command to modify the value of FILLM for the 
SYSTEST account, to display the new value, and to exit from the 
Authorize Utility: 

UAF> MODIFY SYSTEST/FILLM=new-value 
UAF> SHOW SYSTEST 
UAF> EXIT 
$ 

Restart the UETP. The UETDISKOO test image should execute correctly. 


3.2.6.4 Error Messages Sometimes Display an Incorrect Unit Number 

The largest unit number that the UETP outputs in the %UETP-E-DESTP 
error message is 511. Therefore, if an error is generated on a device with a 
unit number greater than 511 and testing of the device stops, the %UETP-E- 
DESTP error message displays an incorrect unit number. 

For example, if an error terminates the UETDISKOO disk test image on device 
DUA513, the following error message results: 

********************** 

* DISK_NODE$DUA * 

* Error count = n * 

********************** 

-UETP-E-TEXT, RMS file error in file N0DE$DUA513:N0DE$DUA513.TST 
-RMS-E-CRE, ACP file create failed 
-SYSTEM-F-EXQUOTA, exceeded quota 

•/.UETP-E-DESTP, DISK_NODE$DUA stopped testing N0DE$DUA unit 1 at 10:24:26.13 

If the unit number of the disk is greater than 511, add 512 to the unit number 
output by the %UETP-E-DESTP error message to obtain the actual unit 
number of the disk. 


3.2.6.5 Defining a Remote Node for UETP Ethernet Testing 

When the UETUNASOO test of the User Environment Test Package (UETP) 
executes, it is sometimes difficult to determine whether the problems it reports 
concern the device under test or the remote device. To ensure that the test 
properly reports errors on the device being tested, define a "good turnaround." 
A "good turnaround" is a remote node that you know turns around Ethernet 
network control packets correctly and is up and waiting in the ready state. 

You can make the UETUNASOO test use a known "good turnaround" by 
performing the following actions. In the commands that follow, assume that 
the "good" device is on node BETA and that node BETA is already defined in 
the network database. 

1 Find the address of the "good" Ethernet node by using the Network 
Control Program (NCP). In order to use NCP, the following conditions 
must apply: 

• DECnet must be up and running on the system. 
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• The account you are using must have TMPMBX and NETMBX 
privileges. 

Enter the following commands: 

$ RUN SYSSSYSTEM:NCP 

NCP> TELL BETA SHO CHAR ACTIVE LINES 


If node BETA has not been defined in your network database, NCP 
displays an error message. In this event, specify another "good" node and 
reenter the command. If you cannot find a "good" node, see your system 
or network manager. 

NCP displays information similar to the following: 


Active Line Volatile Characteristics as of 
Line = UNA-0 
Counter timer 

Receive buffers = 

Controller = 

Protocol = 

Service timer = 

Hardware address = 

UNA device buffer size = 


15-0CT-1986 16:13:02 

28800 

6 

normal 

Ethernet 

4000 

AA-00-04-00-46-D3 

1498 


2 Use the displayed hardware address — in this case, AA00040046D3 — to 
define the logical name TESTNIADR to point to the "good turnaround." 
Note that you do not specify the hyphens (-). 

First, log in to the SYSTEST account; then, enter the following command: 

$ DEFINE/SYSTEM TESTNIADR AA00040046D3 


3 Run the UETP. 

4 When UETP has completed, deassign the logical name TESTNIADR by 
entering the following command: 

$ DEASSIGN/SYSTEM TESTNIADR 


3.2.7 VAX/VMS Support of the VAX-11 /782 Processor 

Version 4.7 is the final version of VAX/VMS that supports the the 
VAX-11/782 processor. The next major version of VAX/VMS will not 
support the VAX 11/782. 

If you have a VAX-11/782 processor, you have the following four options: 

• You can continue to use VAX/VMS Version 4.7 and never upgrade to the 
next major version of VAX/VMS. 

• You can divide the processor into two VAX-11/780 processors. 

• If you want to continue using multiprocessing, you can replace your 
VAX-11/782 with a VAX 8350. 

• If your VAX-11/782 processor was used primarily as a performance 
accelerator, you can replace the VAX-11/782 with an VAX 8600. 

Contact your DIGITAL sales representative for further information about 
these options. 
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3.2.8 VAXTPU EDT Keypad Emulator Support 

The VAXTPU EDT Keypad Emulator emulates all keypad functions and some 
line editing commands of the EDT editor. The EDT Keypad Emulator is 
supplied in both source and compiled format in Version 4.7 of VAX/VMS. 

In the next major release of the operating system, the EVE editor will 
include support for the EDT keypad. VAX/VMS will no longer supply 
the EDTSECINI.TPU file. If you want to continue using the VAXTPU EDT 
Keypad Emulator, we recommend that you save a copy of EDTSECINI.TPU 
and recompile it after upgrading to the next major version of VAX/VMS. 


3.2.9 Asynchronous DDCMP Driver (NODRIVER) — Problem Fixed 

Received-message processing by the asynchronous DDCMP driver 
(NODRIVER) has been updated to correct previous message processing 
errors. 


3.2.10 Synchronous Driver for DMF32 (XGDRIVER) — Problem Fixed 

Received-message processing by the synchronous driver for DMF32 
(XGDRIVER) has been updated to correct previous message processing 
errors. 


3.2.11 DECnet Now Starts Correctly on Satellite Nodes 

In VAX/VMS Version 4.6, when a satellite node was added to a Local Area 
VAXcluster system, the file NETNODE_REMOTE.DAT was always deleted 
from the satellite's root directory. As a result, DECnet could not be started 
on the satellite node unless a NETNODE_REMOTE.DAT file existed in the 
system common root directory. VAX/VMS Version 4.7 corrects this problem. 

In Version 4.7, the NETNODE_REMOTE.DAT file is deleted from the 
satellite's root directory only if a NETNODE_REMOTE.DAT file exists in the 
system common root directory or if the logical name NETNODE—REMOTE is 
defined. 


3.2.12 DECnet-VAX Device Protection — Problem Fixed 

VAX/VMS Version 4.7 corrects a problem with DECnet-VAX device 
protection that occurred in Versions 4.5 and 4.6. Before Version 4.7, when 
users changed a terminal line to an asynchronous DECnet line and then 
restored the line to a terminal line, the original device protections were not 
restored. Version 4.7 corrects this problem and restores the original device 
protection to the terminal line. 


3.2.13 DECnet-VAX MAXIMUM RECALLS Parameter— Problem Fixed 

Before Version 4.7, the maximum value for the DECnet X.25 outgoing data 
link mapping (DLM) circuit parameter MAXIMUM RECALLS was 254. This 
error has been corrected. The maximum value of this parameter is now 255. 
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3.2.14 VAXcluster Performance Advisor-Caused Crashes — Problem Fixed 

Before Version 4.7, if the VAXcluster Performance Advisor (VPA) optional 
software product was running on a node in the cluster, shutting down or 
crashing a node that served local disks sometimes caused the node running 
VPA to crash. Version 4.7 corrects this problem; when a node that serves 
local disks is shut down or crashes, the node running VPA does not crash. 


3.2.15 Batch/Print Facility — Notes 

The following notes pertain to the Batch/Print facility. 


3.2.15.1 Non-printable Characters Counted — Problem Fixed 

Before Version 4.7, the print symbiont counted some non-printable characters 
as printable characters, thus increasing the column position count and the line 
count maintained by the symbiont. Because the column count was too high, 
the print symbiont wrapped text sooner than it should have, resulting in the 
following problems: 

• Tab characters were expanded incorrectly due to errors in horizontal 
positioning. 

• More lines than necessary were printed, increasing accounting 
information for the number of QIO PUTs and the number of pages 
printed. 

The Version 4.7 print symbiont does not count non-printable characters as 
printable characters. 


3.2.15.2 PRINT Command — Accounting Problem Fixed 

Before Version 4.7, the Accounting Utility was unable to count the number 
of pages in a job submitted with the PRINT/NOFEED command. The 
/NOFEED qualifier to the PRINT command prevents the print symbiont from 
performing pagination. The Version 4.7 print symbiont counts form feeds, 
vertical tabs, and page overflows to determine the number of pages in a job 
submitted with the PRINT/NOFEED command. 


3.2.15.3 /SHEET_FEED Qualifier to DEFINE/FORM Command — Correction 

The Versions 4.4 through 4.6 print symbionts disabled the /SHEET_FEED 
qualifier to the DEFINE/FORM command. The Version 4.7 print symbiont 
reenables the /SHEET_FEED qualifier. The DEFINE/FORM/SHEET__FEED 
command causes the print symbiont to pause after printing each page of a 
document by placing the queue in the pending state. 


3.2.15.4 /SHEET_FEED Qualifier to DEFINE/FORM Command — Restriction 

Do not use the /PAGES qualifier to the PRINT command when submitting 
jobs to queues on which the DEFINE/FORM/SHEET_FEED command has 
been issued. When used with the /SHEET_FEED qualifier, the /PAGES 
qualifier causes the print symbiont to enter an infinite loop. The last page of 
the document prints repeatedly; the symbiont pauses after each page prints. 
If you encounter this problem, enter the following commands to stop and 
restart the queue: 


$ STOP/QUEUE/RESET queue-name 
$ START/QUEUE queue-name 
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3.2.15.5 Device Control Libraries — Problem Fixed 

Before Version 4.7, the print symbiont sometimes left device control libraries 
open. To enhance performance, the print symbiont operates asynchronously 
most of the time. Device control libraries cannot operate in asynchronous 
mode. When an asynchronous request to stop a task or stream interrupted a 
close operation for a device control library, the device control library was left 
open. 

Prior to Version 4.7, the print symbiont opened the device control library as 
each task started and closed it after each task completed. The Version 4.7 
print symbiont opens the device control library when a stream is started and 
closes the device control library when the stream is stopped. This prevents 
the close operation from being interrupted by an asynchronous request. 

This change to the print symbiont results in two additional benefits: 

• The print symbiont performs more efficiently because the device control 
library is opened and closed less frequently. 

• The device control library is more secure; it cannot be modified when it is 
attached to an active stream. 


3.2.15.6 Tab Expansion Determined at Start of Queue 

When the output queue is started, the print symbiont determines if tab 
expansion is required by accessing the current device characteristics. The 
print symbiont expands horizontal tabs only when the device is incapable 
of handling the tab character. On a device controlled by the LCDRIVER or 
LPDRIVER, the DCL command SET PRINTER/TAB sets the tab characteristic 
for that device. On a serial line controlled by the terminal driver, the DCL 
command SET TERMINAL/TAB sets the tab characteristic for that serial 
device. 

The device characteristics for an output queue are determined when the queue 
is started. Therefore, DIGITAL recommends setting the device characteristics 
before starting the output queue. If the characteristics of a device need to 
be reset after the output queue has been started, DIGITAL recommends 
stopping the queue, resetting the device characteristics, and then restarting 
the output queue. Please be sure the output queue has stopped completely 
before changing the device characteristics. 


3.2.15.7 Generation of Blank Pages 

In Version 4.0 of VAX/VMS, it was possible to create library setup/reset 
modules that were output to the device during the processing of the current 
print job. Setup or reset modules could be output before a specific file, before 
all files, or after the current job is completed. The Version 4.0 print symbiont 
incorrectly inserted form feeds after all setup or reset modules regardless 
of content. In VAX/VMS Version 4.4 and subsequent versions, only those 
modules that insert printable text are followed by a form feed. No form feed 
is inserted after a recognized escape sequence, device control sequence, or 
operating system command. 

DIGITAL realizes that certain limitations exist for output devices that require 
control sequences in the ASCII range of printable characters. Certain 
limitations may also exist for those devices that allow the user to reposition 
output to the top of the page after insertion of printable text. DIGITAL 
believes this area of the symbiont may require additional flexibility beyond 
that which is currently provided and will continue to investigate these issues. 
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3.2.15.8 Device Reset Sequence and Form Feed Interaction 

Blank pages issued between jobs may be due to interactions between form 
feed and the device reset escape sequence. Certain programmable devices 
require the form feed to precede the reset sequence. Extra page problems may 
be resolved on such devices by inserting a form feed before the reset escape 
sequence in the device control library module. 


3.2.16 SET TIME/CLUSTER — Problem Fixed 

VAX/VMS Version 4.7 fixes a problem that caused the SET TIME/CLUSTER 
command to report incorrect timeout errors on large clusters. 

The SET TIME/CLUSTER command will be superseded by a more general 
mechanism for handling clusterwide system management in the next major 
release of the VAX/VMS operating system. 


3.2.17 Installing Optional Software Products on Tailored Systems 

Sites using small-disk tailored systems must perform the following editing 
operation before installing any of the VAX/VMS optional software products 
listed in Table 3-1. Optional software products not listed can be installed 
normally. Please refer to the System Software Order Table (SPD 28.98.xx) for 
the latest versions of these optional software products and for the processor 
configurations supported by each. 

1 Log in to the SYSTEM account. 

2 Set the default directory to SYS$ UPDATE, by entering the following 
command: 

$ SET DEFAULT SYS$UPDATE 

3 Using a text editor, edit the file LIBRARY.TLR and remove the following 
line: 

[SYSEXE]SYS.STB 

4 Exit from the text editor, thus creating a new version of the file. 

5 Using the text editor, edit the file REQUIRED.TLR and add the following 
line: 

[SYSEXE]SYS.STB 

6 Exit from the text editor, thus creating a new version of the file. 

7 Invoke the Tailoring command procedure and rename the library disk file 
as follows: 


$ OSYS$UPDATE:vmstailor 
TAIL0R> DISMOUNT 

TAIL0R> MOUNT/WRITE ddcu: ! where ddcu: is the library disk 
TAIL0R> COPY/FILE SYS.STB ! copies SYS.STB to the system disk [SYSEXE] 

! using the default source and target 
! locations 


TAIL0R> EXIT 

$ SET DEFAULT ddcu:[SYSO.SYSEXE] ! 
$ RENAME SYS.STB LIBSYS.STB ! 

i 

j 


where ddcu: is the library disk 
Rename the library disk version; 
the file remains unchanged on the 
system disk. 
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8 Enter the following command to reset the default directory to 
SYS$UPDATE: 

$ SET DEFAULT SYS$UPDATE 

9 Install the optional software product using VMSINSTAL. 

This operation ensures that products requiring the system global symbol table 
at link time during installation will find the file in the REQUIRED file group. 
All files that are not members of the REQUIRED file group are tailored to the 
library disk by VMSINSTAL during installation. The system disk is restored 
to its original configuration upon completion of the VMSINSTAL command 
procedure. 

Step 7 above ensures that VMSINSTAL does not find SYS.STB on the library 
disk and prevents its subsequent forced removal from the system disk, which 
would cause the installation to fail. Renaming the file on the library disk 
allows you to maintain a backup copy. 

Any "File not found" messages that occur during installation of an optional 
software product can be corrected by repeating the previously listed steps to 
move the file to the system disk. 

See Section 3 of the VAX/VMS System Manager's Reference Manual for 
additional information. 

Table 3-1 Products That Require the Editing Operation for 
Installation on a Tailored System 


ALL-IN-1 

DRB32 VMS DRIVERS 
DRX11-C VMS DRIVER 
IEX-VMS-DRIVER 
MUX200/VAX 

VAX COMMON DATA DICTIONARY 
VAX DBMS 

VAX DRE11-C DEVICE DRIVER 

VAX DRIVER FOR 11C03 

VAX DEC/MAP 

VAX PRODUCER 

VAX PRODUCER INTERPRETER 

VAX SPM 

VAX TDMS 

VAX-11 TSU05 DEVICE DRIVER 

VAXINFO I 

VAXINFO II 

VAXINFO III 

VS11-VAX DRIVER 
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3.2.18 Booting From Multiple UDA50 Systems — Restrictions 

If you plan to bootstrap from a UDA50-supported device, there are two 
restrictions you must keep in mind when you configure your system: 

1 Each UNIBUS up to (but not including) the one that supports the 
bootstrap device must have exactly one UDA50. Each UNIBUS, from 
the bootstrap device upwards, can have up to the legally allowable 
number of UDA50s. 

2 You can bootstrap only from the first UDA50 on a UNIBUS (that is, the 
one with the fixed CSR and vector). 

If your system is a VAX-11/750, then the maximum unit number that can be 
bootstrapped is hexadecimal 'F' (decimal 15). 


3.2.19 DMB32 Product Software Required for DMB32 Communications 
Controller 


VAX 8200/8250/8300/8350 and VAX 8530/8550/8700/8800 systems that 
include the DMB32 communications controller must install the DMB32 
optional software product in order to use the controller's synchronous port. 
The VAX/VMS kit does not contain the DMB32 software. 


3.2.20 Permanent MONITOR Server Processes 

Creating permanent MONITOR server processes on each member node in a 
cluster at bootstrap time can significantly reduce server startup time. 

To create such a process, add the following lines to the appropriate startup 
command procedures. Be sure that you allot a page file quota of at least 
10,000 pages. 

$ DEFINE/SYSTEM/EXECUTIVE_M0DE VPM$SERVER_LIVE TRUE 
$ RUN/DETACH/PAGE_FILE=10000 SYS$SYSTEM:VPM.EXE 

You can also enter these commands interactively at any time from an account 
that has the following privileges: ALTPRI, NETMBX, PSWAPM, SYSNAM, 
SYSPRV, and TMPMBX. 


3.2.21 MONITOR CLUSTER — Misleading I/O Rates for MSCP Served Disks 

The MONITOR CLUSTER command for the MONITOR utility can produce 
misleading I/O rates for mass storage control protocol (MSCP)-served disks. 

For MSCP-served disk I/O, VAX/VMS increments the operation count on the 
remote node and the node on which the disk is served. When you enter the 
MONITOR CLUSTER command, MONITOR calculates the displayed I/O rate 
by calculating the sum of the operation counts for all contributing nodes. As 
a result, MONITOR counts some I/Os more than once; reported I/O rates for 
MSCP-served disks might be higher than actual rates. 

To produce more meaningful I/O rates for MSCP-served disks, use the 
MONITOR DISK command on the nodes that serve the disk. For each disk, 
the sum of these I/O rates is the rate of actual I/Os issued in support of all 
remote and local I/O requests for that disk. 
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3.2.22 LAT Print Symbiont (LATSYM) — Problems Fixed 

Version 4.7 corrects the manner in which the LAT print symbiont (LATSYM) 
processes some error conditions. The LATSYM process no longer loops 
nor crashes when it encounters these error conditions. The Version 4.7 
LATSYM.EXE image is larger than the V4.6 version, since it now includes 
nonshareable copies of the VMS common print symbiont routines. 


3.2.23 LAT Control Program — Problems Fixed 

The following two LAT problems have been fixed in VAX/VMS Version 4.7: 

• You no longer receive the "repeat create of slot by server" error message 
when a channel is assigned to an interactive LAT device by another 
process. 

• The STOP NODE command no longer causes a VAX 8800 processor to 
fail (crash). 


3.2.24 LAT-11 Optional Software Product — Problems Fixed 

This section discusses problems and limitations when using the LAT-11 
software that runs on a PDP-11 configured to serve terminals. 


3.2.24.1 Bad Message Received Error 

The LAT-11 software registers a bad message received error for a service 
node that sends out a configuration message without any services. This can 
happen if an incorrect sequence is used when starting up the service node. 
Include the following command sequence in the LTLOAD.COM file to start 
up the service node automatically, or enter the following command sequence 
interactively to start up the service node manually: 

1 Include the SET NODE command to set the node name and characteristics 

2 Include the CREATE SERVICE and LCP SET SERVICE commands to set 
up the services for the node 

3 Include the START NODE command to start LAT service on the node 

The LAT-11 software also registers a bad message received error if a service 
node offers more than two services. Do not enable more than two services on 
any node accessed by LAT-11. 

3.2.24.2 Cluster Nodes Not Accessible by LAT-11 

The LAT-11 software requires that the first service name offered by a 
VAX/VMS node be the node name. For a VAXcluster, the cluster service 
name must be the second service name offered by the VAX/VMS node. All 
other DIGITAL terminal server products require only a cluster service name. 

Add the following command line to your LTLOAD.COM file before the 
command line that starts the node: 

$ LCP CREATE SERVICE cluster-service-name /IDENTIFICATION/NOLOG 
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The sample LTLOAD.COM file in Example 3-1 shows you where to enter 
this command line. 

Example 3—1 Sample LTLOAD.COM File for Use with LAT-11 


$ ! This command procedure starts up the LAT protocol and 
$ ! is compatible with LAT-11. 

$ ! 

$ RUN SYSSSYSTEM:SYSGEN 
CONNECT LTAO/NOADAPTER 

$ ! 

$ ! Invoke LATCP 
$ ! 

$ LCP := $ LATCP 
$ ! 

$ ! The following commands set up LAT service with the 
$ ! default name SYSSNODE and default ident SYS$ANNOUNCE. 

$ ! The first LAT service name defaults to the node name 
$ ! SYS$NODE. YOU MUST SPECIFY a clusterwide service name 
$ ! as the first parameter in the command line. Use the 
$ ! remaining parameters to specify values for other node 
$ ! characteristics,such as group codes. 

$ ! 

$ LCP SET NODE /IDENTIFICATION •P2' •P3' •P4• /NOLOG 
$ LCP CREATE SERVICE /IDENTIFICATION ! Fix for LAT-11 bug 
$ ! Provide cluster service name as PI 
$ LCP CREATE SERVICE 'PI' /IDENTIFICATION/NOLOG 
$ LCP START NODE 
$ EXIT 


3.2.24.3 New Features Not Supported 

The LAT-11 software does not support the new functions provided by the 
Version 4.7 LAT/VMS software. You cannot connect a remote printer using 
the LAT-11 software. However, all LAT functions previously supported by 
LAT-11 still work with VAX/VMS Version 4.7. 


3.2.25 LAT/VMS Problems 

This section discusses problems affecting the LAT/VMS software and 
suggested solutions for those problems. 


3.2.25.1 Delay in Process Disconnect 

If virtual terminals are enabled on your system and you enter a terminal 
server DISCONNECT command, the process is not deleted immediately. 
The process is deleted when the timeout period expires. This is normal and 
should be expected. 
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3.2.25.2 LATCP Command STOP NODE 

The STOP NODE command deletes the current node characteristics. Avoid 
using the following sequence of commands: 

LCP> STOP NODE 
LCP> START NODE 

Instead of using these commands, invoke the LTLOAD.COM file or set up 
the characteristics for your node manually with the SET NODE and SET 
SERVICE commands. 

Note that, if you enter the LATCP command STOP NODE, all LAT terminal 
users are disconnected from the node and a process rundown is initiated. 


3.2.25.3 LATCP and the DELETE PORT command 

The DELETE PORT command does not shut down a session correctly when 
it is used on a port with an active session. Use the DELETE PORT command 
only for inactive application ports. 

3.2.25.4 Solicit Connection QIO 

Do not enter the solicit connection QIO if LATCP has not yet started the LAT 
protocol. The QIO request may not complete and will not return an error. 


3.2.25.5 LAT PASSALL Session 

When using a host-initiated connection with the UCB set to the PASSALL 
characteristic, the terminal server's input flow control for the port is disabled. 
This is normal behavior. 

3.2.26 Booting a Satellite Node During SATELLITE_CONFIG.COM ADD Phase 

When a Local Area VAXcluster satellite node boots during the SATELLITE- 
CONFIG.COM procedure's ADD phase, another command procedure, 
SYS$MANAGER:NETCONFIG.COM, executes. NETCONFIG.COM invokes 
the Network Control Program (NCP) and Authorize Utilities, which display 
various informational and error messages. You can ignore these messages. 


3.2.27 Rebooting a Satellite Node With an Operating System On a Local Disk 

In some circumstances, cluster software reboots Local Area VAXcluster 
satellite nodes automatically. Before booting a satellite node, the boot 
procedures check for the presence of an operating system on the node's 
local disk. If an operating system (for example, a Micro VMS system) is found, 
that system — not the Local Area VAXcluster system — is booted. 

If an operating system is installed on a satellite's local disk, one 
of the following measures should be taken before performing any 
operation that causes an automatic reboot — for example, executing 
SYS$SYSTEM:SHUTDOWN.COM with the REBOOT option or using 
SATELLITE_CONFIG.COM to add that node to the cluster: 

• Rename the directory file ddcu:[000000]SYS0.DIR on the local disk to 
ddcu:[000000]SYSx.DIR (where SYSx is a root other than SYSO or SYSE). 
In the following example, SYSO is renamed SYS1: 

$ RENAME DUAO:[000000]SYSO.DIR DUAO: [000000]SYS1.DIR 
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Then enter the DCL command SET FILE/REMOVE to remove the old 
directory entry for the boot image SYSBOOT.EXE. 

$ SET FILE/REMOVE DUAO: [SYSEXE]SYSBOOT.EXE; 

For subsequent reboots of the system from the local disk, enter a 
command in the format B/xOOOOOOO at the console-mode prompt 
(> > > ), as in the following example: 

»> B/10000000 

• Disable the local disk. To disable the local disk on MicroVAX II or 
VAXstation II machines, press the READY button so that the light is off. 
(This option is not available if the satellite's local disk is being used for 
paging and swapping.) 


3.2.28 Dual-Ported Non-DSA Disks in a VAXcluster — Restriction 

Do not enter the SYSGEN commands AUTOCONFIGURE or CONFIGURE 
to configure a dual-ported, non-DSA disk that is already available on the 
system via an MSCP server. Establishing a local connection to the disk when 
a remote path is already known creates two uncoordinated paths to the 
same disk. Use of these two paths can corrupt files and data on any volume 
mounted on the drive. 

In a VAXcluster, dual-ported non-DSA disks (MASSBUS or UNIBUS) can be 
connected between two nodes of the cluster. These disks can also be made 
available to the rest of the cluster using the MSCP server on either or both of 
the hosts to which a disk is connected. 

If the local path to the disk is not found during the bootstrap, then the MSCP 
server path from the other host is the only available access to the drive. The 
local path is not found during a boot if any of the following conditions exist: 

1 The port select switch for the drive is not enabled for this host. 

2 The disk, cable, or adapter hardware for the local path is broken. 

3 There is sufficient activity on the other port to "mask" the existence of the 
port. 

4 The system is booted in such a way that the SYSGEN command 
AUTOCONFIGURE ALL in the SYS$SYSTEM:STARTUP.COM procedure 
was not executed. 

Use of the disk is still possible through the MSCP server path. 

Once the configuration of the disk has reached this state, it is important 
not to add the local path back into the system I/O database. Since there 
is no automatic method for this to occur in VAX/VMS, the only possible 
way that this could occur would be to use the SYSGEN Utility command 
AUTOCONFIGURE or CONFIGURE to configure the device. SYSGEN 
is currently not able to detect the presence of the disk's MSCP path and 
incorrectly builds a second set of data structures to describe it. Subsequent 
events could lead to incompatible and uncoordinated file operations, which 
might corrupt the volume. 

In order to recover the local path to the disk, it is necessary to reboot the 
system connected to that local path. 
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Note that, if the disk is not dual-ported or is never MSCP-served on the 
remote host, this restriction does not apply. 


3.2.29 Some VAX Hardware Names Not Recognized 

The VAX 8250, VAX 8350, and VAX 8530 are new VAX processors. The 
VAX 8250 and VAX 8350 are enhanced systems that provide greater 
performance than the standard VAX 8200 and VAX 8300. These processors 
use the KA825 CPU instead of the KA820 CPU; the KA825 is 20 percent 
faster than the KA820. The VAX 8530 is an enhanced 8500 system with new 
microcode that provides a 33 percent increase in performance. 

VAX/VMS utilities, such as SYSGEN, SDA, SHOW CLUSTER, and the 
GETSYI system service, have not yet been modified to recognize the three 
new VAX model numbers. This results in VAX/VMS incorrectly identifying 
the new systems with the older VAX model number. A future release of the 
operating system will correctly identify the new systems. 

You can make the distinction between the VAX 8200/8300 and the 
VAX 8250/8350 using the ANALYZE/ERROR utility. Each error log entry for 
the VAX 8250 and 8350 systems correctly identifies the CPU type as KA825. 
You can also use the System Dump Analyzer (SDA) to examine the System 
Identification (SID) register as follows: 

$ ANALYZE/SYSTEM 
SDA> SHOW CRASH 

You can find the SID under the listing of the internal processor registers. The 
VAX 8250/8350 systems have bit 23 of the SID set to one, while the 
VAX 8200/8300 systems have bit 23 set to zero. 


3.2.30 AUTOGEN Command Procedure 

The following problems with the AUTOGEN command procedure have been 
corrected in Version 4.7. 


3.2.30.1 Possible DEQNA Problem Avoided 

Under heavily loaded conditions, the DEQNA Ethernet adapter in a large 
and complex Ethernet configuration may receive corrupted data. To avoid 
this problem, AUTOGEN enables software receive packet checksumming 
by setting the value of the SYSGEN parameter PE5 to 2 on Local Area 
VAXcluster members with DEQNAs. 

Since AUTOGEN cannot distinguish between DELQAs and DEQNAs, Local 
Area VAXcluster members with DELQAs receive a value of 2 for PE5, as 
well. DELQAs do not exhibit this problem; therefore, if you have Local 
Area VAXcluster members with DELQAs, you might want to explicitly set 
PE5 equal to 0 in MODPARAMS.DAT for those nodes to avoid the cost of 
software receive packet checksumming. 
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3.2.30.2 VMSIMAGES.DAT Not Created for Version 4.6 

VMSIMAGES.DAT, the default installed image list, was not created on 
some Micro VAX systems that were upgraded from Micro VMS Version 4.5 to 
VAX/VMS Version 4.6. These systems were upgraded from the MicroVMS 
operation system to the VAX/VMS operating system in order to form a Local 
Area VAXcluster environment. VMSIMAGES.DAT was created correctly for 
all sites that installed VAX/VMS Version 4.5A or VAX/VMS Version 4.6 on 
Micro VAX systems. 

In Version 4.7, AUTOGEN guarantees that VMSIMAGES.DAT is created for 
all Local Area VAXcluster members. 


3.2.30.3 LOCKDIRWT Parameter Calculation Corrected 

In Version 4.6, the value of the SYSGEN parameter LOCKDIRWT was 
incorrectly calculated for all Local Area VAXcluster members that had a 
VAX 8530 as a boot node. This is the only configuration in which this 
problem existed. When you run AUTOGEN after completing the Version 
4.7 update, the value for the SYSGEN parameter LOCKDIRWT is calculated 
correctly. 


3.2.31 Diskette Devices and the MSCP Server 

The Mass Storage Control Protocol (MSCP) does not allow all the functions 
associated with a diskette device. Therefore, the MSCP Server (which is 
based upon MSCP) does not allow diskette devices such as the RX01, RX02, 
and RX33 to be served. See the VAX/VMS DCL Dictionary and VAX/VMS 
System Manager's Reference Manual for more information. 


3.2.32 Protection of Security Auditing Information 

Because the operator log file (SYS$MANAGER:OPERATOR.LOG) contains all 
of the security auditing information, it is possible to lose auditing information 
if the disk on which this file resides becomes full. 

While a well managed system will normally have adequate storage capacity, 
unexpected circumstances can cause excessive consumption of disk space. If 
all blocks on the disk are in use, a situation may arise where audit data could 
be lost. The National Computer Security Center (NCSC) has requested, as 
part of the evaluation of the VAX/VMS operating system, that a warning be 
issued whenever this condition occurs. 

The NCSC requirement is that a message be issued prior to any audit data 
being lost and in sufficient time to allow the corrective action to be taken 
before all free blocks are exhausted. 

To honor this requirement, DIGITAL is supplying the following procedure 
for users who want to operate VAX/VMS as a Class C2 evaluated system. 
This procedure samples the available free blocks at a specified interval. The 
default sampling interval is every ten minutes. If the free space on the disk is 
less than a specified threshold, warning messages are issued to all terminals 
that have been enabled as operator terminals. The default threshold is 1% of 
the maximum available blocks. 
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The following command procedure, while fully functional, is provided as a 
guideline to be tailored to your specific requirements: 

$ ! SYS$MANAGER:AUDIT_GUARD.COM 

$ ! 

$ ! Procedure to protect the audit trail when the system disk is 
$ ! approaching capacity. 

$ ! 

$ ! User adjustable parameters. If no parameters are specified on the 
$ ! command line, supply the default values. 

$ $ IF Pl.EQS."" THEN 
$ PI = "00:10" 

$ IF P2.EQS."" THEN 
$ P2 = 1 
$ ! 

$ INTERVAL = PI ! Sample remaining disk space at 10-minute intervals 

$ THRESHOLD = P2 ! Report shortage when 1*/, of disk blocks are free 

$ ! 

$ ! Determine the parameters for the device on which the operator log file 
$ ! is located. 

$ ! $ SET PR0CESS/PRIVILEGE=0PER 

$ LOG.FILE = F$SEARCH("SYS$MANAGER:OPERATOR.LOG") ! For search lists 
$ IF LOG.FILE.EQS."" THEN 
$ GOTO N0_L0G_FILE 

$ ! $ AUD.DEV = F$PARSE (LOG.FILE,,,"DEVICE","N0.C0NCEAL") 

$ MAX.BLOCKS = F$GETDVI(AUD.DEV,"MAXBLOCK") 

$ FREE.BLOCK.LIMIT = (MAX.BLOCKS * THRESHOLD)/100 
$ ! 

$ ! Sit in a loop, checking the amount of available free space. 

$ ! $ C2.L00P: $ REMAINING = FSGETDVI(AUD.DEV,"FREEBLOCKS") 

$ IF (REMAINING .GT. FREE.BLOCK.LIMIT) THEN 
$ GOTO PAUSE 
$ ! 

$ ! If the amount of free space drops below the selected threshold, report 
$ ! the condition. 

$ ! 

$ REQUEST "ONLY "REMAINING' BLOCKS AVAILABLE ON AUDIT TRAIL DISK!" 

$ REQUEST "PLEASE TAKE CORRECTIVE ACTION!" 

$ ! 

$ ! Wait before checking the free space. 

$ ! 

$ PAUSE: 

$ WAIT 'INTERVAL' ! Wait the interval before looking again. 

$ GOTO C2.L00P ! Time to look again 

$ ! 

$ ! If there is no log file, report it, and then exit cleanly. 

$ ! 

$ NO.LOG.FILE: 

$ REQUEST "NO AUDITING INFORMATION KEPT DUE TO MISSING OPERATOR LOG FILE" 

$ ! 

$ EXIT 

You can edit command procedure to be sure its operation is appropriate for 
your specific environment. You can redirect messages to a specific device 
(for example, OP AO:) by using the REPLY command or to a specific operator 
function by using the /TO= switch with the REQUEST command. You may 
also want to alter the sampling rate and threshold used by this procedure. 
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The two parameters for doing this follow: 

INTERVAL Delta time used to control the sampling rate for checking the 
remaining disk space and issuing the warning message. 

THRESHOLD Value representing a percentage of free blocks remaining on the 
disk relative to the total available blocks. Warning messages are 
generated if the percentage of free blocks remaining on the disk 
falls below this value. 

When you run the command procedure, messages are output at the sampling 
rate specified by the INTERVAL parameter until action has been taken to 
increase the number of available free blocks above the THRESHOLD value. 

Once started, this procedure continues to execute until it is either stopped by 
a privileged user or until the system is rebooted. 

To ensure that this procedure executes each time you bootstrap the system, 
add the following command to your site-specific startup command procedure 
(SYS$MANAGER:SYSTARTUP.COM): 

$ SUBMIT SYSSMANAGER:AUDIT_GUARD /NOLOG 


3.2.33 Forced Error Handling 

Most VAX/VMS utilities and DCL commands treat the presence of the forced 
error flag as a fatal error. For example, if you use the DCL command COPY 
to move a file that contains a block with the forced error flag, the resulting 
error causes the operation to terminate. 

The Backup Utility, however, is designed to continue in the presence of 
almost all errors, including forced errors; BACKUP continues to process the 
file, creating a new copy of the file in the output saveset. An error message 
indicating the forced error is displayed, but the forced error is not present in 
the new copy of the file that is being created. Subsequent use of the new file 
(for example, in a restore operation) will indicate no errors. Thus, data that 
was formerly marked as bad with the forced error flag may be accidentally 
propagated and now seem correct. 

System managers (and other users of BACKUP) should assume that forced 
errors reported by BACKUP signal degradation of the data in question and 
should act accordingly. The safest procedure is to replace the file containing 
the forced error with a good copy of the file from a previous BACKUP 
operation. 

For more information on DIGITAL Storage Architecture (DSA) and forced 
errors, see the VAX/VMS I/O User's Reference Manual: Part 1. 


3.2.34 SYSGEN — Notes and Restrictions 

This section contains information related to the System Generation Utility 
(SYSGEN). 
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3.2.34.1 UDABURSTRATE Parameter 

The UDABURSTRATE parameter is dependent upon configuration and 
workload. Alteration of the default value can have serious side effects. 
Consult your DIGITAL Field Service representative before changing the 
default value of this parameter. 


3.2.34.2 SYSGEN Confuses CONSOL.SYS on VAX-11 /780 and VAX-11 /785 
Systems 

If you specify the SYSGEN command CONNECT OPA1 on a VAX 11/780 
or VAX 11/785 system, the console software running in the 11/03 will be 
corrupted. Any attempt to access the console floppy diskette results in an I/O 
timeout and the floppy diskette being unusable. 

Furthermore, if you are attempting to reboot the system from a HSC disk 
controller, the system displays the following message: 

CANNOT FIND Cl MICROCODE FILE 

The message indicates that, although DEFBOO.CMD and VMB.EXE can be 
read without problems, the access path to the front end through the CIB 
board cannot be used. The only strategy is to turn off the power to the 11/03 
subsystem and to reload CONSOLE.SYS. 


3.2.35 User-Created Cluster Quorum File Problem 

The cluster quorum file QUORUM.DAT is automatically created by the cluster 
connection manager when the system is booted for the first time with the 
SYSGEN parameter DISK-QUORUM specified. The connection manager 
creates the quorum file with the appropriate attributes and supplies the initial 
template entry. Therefore, one should not attempt to create a quorum file 
manually. Doing so may cause the quorum disk to be corrupted. 


3.2.36 VMSINSTAL Option N — Compatibility Problem 

Use of the VMSINSTAL Option N to display or print optional software 
product release notes is not compatible with earlier VMSINSTAL 
Option A, which uses autoanswer files to supply answers to questions output 
by the VMSINSTAL command procedure. Because Option N did not exist on 
previous versions of VAX/VMS, there was no way that it could be stored in 
the autoanswer file. As a result, use of an Option A with Option N produces 
the following error messages: 

8 /,VMSINSTAL-F-AUT0SYNC, Autoanswer file is not in synch with questions. 
-VMSINSTAL-F-AUTOSYNC, question: * Select option [3]: 

-VMSINSTAL-F-AUTOSYNC, file: * Do you want to purge files replaced by 

this installation [YES]? 

# / 8 VMSINSTAL-F-UNEXPECTED, Installation terminated due to unexpected event. 
VMSINSTAL procedure done at 14:00 

The solutions are either to not use Option A with Option N or to recreate the 
autoanswer file before installing the optional software product. 

The N option allows the installer to view or print, or both view and print, the 
online release notes for those optional software products that support online 
release notes. 
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Note: Currently, not all optional software products support online release notes. 
Use of Option N in these cases produces no difference in the flow of the 
installation procedure. 


3.3 Application Programmer Information 

This section describes problems resolved in VAX/VMS Version 4.7, lists 
known restrictions, and contains other information of interest to the 
application programmer. 


3.3.1 Appending to Shared Sequential Files 

The use of the RMS Deferred Write option with sequential files opened for 
shared append access could result in file corruption. To avoid corruption, 
the Deferred Write option is automatically disabled for shared sequential 
files. Use of Deferred Write with shared append access to sequential files is 
expected to be reenabled in a future release of VAX/VMS. 


3.3.2 Caution on Use of NOP Instruction as a Delay Mechanism 

DIGITAL recommends that you do not use the VAX MACRO instruction NOP 
(No Operation) as a means of delaying program execution. 

The delay time caused by the NOP instruction is dependent on processor 
type. For instance, the VAX 8600, VAX 8650, VAX 8800, VAX 8700, VAX 
8550, or VAX 8530 processors execute the NOP instruction more quickly than 
other VAX processors. 

Whenever you must have a program wait for a specified time period, you 
should use a macro or code sequence that is not dependent on the processor's 
internal speed. For example, you can use the TIMEWAIT macro, which is 
documented in the Writing a Device Driver for VAX/VMS volume. You can 
also use the Set Timer ($SETIMR) and Wait for Single Event Flag ($WAITFR) 
system services, as described in the VAX/VMS System Services Reference 
Manual, to force such delays. 


3.3.3 Debugger 


The following notes pertain to the debugger. 


3.3.3.1 Debugger — CTRL/Y Problem Fixed 

A problem concerning how the Version 4.6 debugger handled CTRL/Y 
followed by the DCL command DEBUG has been corrected in Version 4.7. 

This problem occurred if a program signaled an informational or success 
message but did not handle the message itself. The following BLISS fragment 
is an example: 

SIGNAL(l) ! Success signal 

WHILE 1 DO (X = .X + 1); ! Infinite loop 
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In such cases, the Version 4.6 debugger correctly intercepted the signal, 
displayed the informational or success message, and let the program continue 
executing. However, if you then interrupted the program with CTRL/Y and 
subsequently tried to invoke the debugger with the DCL command DEBUG, 
the debugger did not suspend execution and did not display its prompt, as 
shown in the following example: 

DBG> RUN PR0G1 
(DEBUG V4.6) 


DBG> GO 

•/.SYSTEM-S-NORMAL, normal successful completion 

! The above is the display of the message associated with SIGNAL(1). 


! Infinite loop 

<CTRL/Y> 

Interrupt 

$ DEBUG 


! Still in an infinite loop. 

Starting with Version 4.7, this problem has been corrected so that the 
sequence CTRL/Y—DEBUG now correctly interrupts a program that has 
signaled an informational or success message without handling that signal, as 
the following example shows: 

DBG> RUN PR0G1 
(DEBUG V4.7) 


DBG> GO 

*/,SYSTEM-S-NORMAL, normal successful completion ! Message for SIGNAL(l). 


! Infinite loop. 

<CTRL/Y> 

Interrupt 
$ DEBUG 

DBG> ! You're out of the infinite loop and back at the prompt. 


3.3.3.2 Using the Debugger on a VAXstation — Problem 

When you invoke the debugger on a VAXstation, the debugger comes up in 
its own window. There is a problem with the handling of CTRL/Y when 
the debugger is running in its own Micro VAX window. CTRL/Y is ignored 
when the keyboard is attached to the debugger window. To make CTRL/Y 
take effect, attach the keyboard to the window from which you invoked the 
debugger (by pointing at that window with the mouse); then, press CTRL/Y, 

This problem will be corrected in a future release of the operating system. 
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3.3.3.3 Debugging SMG Programs — Restriction 

The debugger now uses the VAX/VMS Screen Management Facility (SMG) 
to implement screen mode. If your program also calls SMG routines and you 
debug it with the debugger running on the same terminal, there is likely to be 
interference between your program and the debugger. 

To avoid this problem, debug the program using two terminals. This 
technique is described in Appendix D of the VAX/VMS Debugger Reference 
Manual 


3.3.3.4 SET SCOPE Command 

Before entering the SET SCOPE command, be sure that the module 
containing the elements named in the path name has already been set, either 
dynamically by the debugger or by means of a SET MODULE command. 
Enter the SHOW MODULE command to determine whether a module is 
set (that is, whether its symbols have been loaded into the run-time symbol 
table). 


3.3.3.5 SET IMAGE Command 

When you enter a SET IMAGE command and specify a list of images, only 
the last image in the list is set, as shown in the following example: 

DBG> SET IMAGE A,B,C 

In this example, only image C is set. To set images A, B, and C, enter 
separate SET IMAGE commands for each image. 


3.3.4 Correction to $GETLKI System Service 

The $GETLKI system service does not report user buffer overflow as 
documented for item codes LKI$_LOCKS, LKI$_BLOCKEDBY, and LKI$_ 
BLOCKING in the VAX/VMS System Services Reference Manual When used 
with an item descriptor specifying any of these item codes, $GETLKI does 
not set bit 31 of the return length address in the item descriptor when the 
user-supplied buffer is too small to hold the requested data. 

Before Version 4.5, the LKI$__LOCKS item code, when used on a locally 
mastered lock, caused the entire return length address field to become 
invalid. Version 4.5 (and subsequent versions) partially corrects this behavior, 
so that LKI$_LOCKS works as documented, except that bit 31 is not set as in 
the case described above. The result is that all three $GETLKI item codes that 
return lengthy information (LKI$__LOCKS, LKI$_BLOCKEDBY, and LKI$_ 
BLOCKING) behave in the same (incorrect) fashion. 

Bit 31 of the returned length address never indicates when the user-supplied 
buffer is too small. To solve this problem, DIGITAL suggests the following 
rule: 

The user buffer size may be inadequate if the sum of the low word of the 
returned length and the high word of the returned length is greater than 
the size of the user buffer supplied. 

DIGITAL expects to correct this problem in a future release of the operating 
system. 
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3.3.5 Ethernet Protocol Types are Validated — Restriction 

Since Version 4.6, the protocol type parameter has been validated whenever 
you start a channel to an Ethernet driver that receives messages in Ethernet 
packet format. Valid protocol types range from 05-DD (hexadecimal) to FF-FF 
(hexadecimal). If you specify an illegal protocol type value, the start request 
fails and you receive the error message SS$_BADPARAM. 


3.3.6 The Broadcast Address Must be Enabled to Receive Broadcast Messages 
— Planned Change 

In the next major release of the VAX/VMS operating system, broadcast 
messages will be delivered to an Ethernet application only if the application 
has enabled the broadcast address as a multicast address. If your Ethernet 
application requires acceptance of broadcast messages to successfully complete 
READ requests, the application should enable the broadcast address as a 
multicast address. Make this modification to your Ethernet application before 
installing the next major release of VAX/VMS operation system software. 
This will ensure that your Ethernet application will continue to operate 
properly when the new Ethernet driver is installed. 


3.3.7 NMA$C_PCLI_PAD Parameter for Ethernet Packet Format Only — 
Planned Change 


In the next major release of the VAX/VMS operating system, the NMA$C_ 
PCLI—PAD parameter will be valid only for Ethernet channels that have 
the NMA$C_PCLI_FMT parameter set to NMA$C_LINFM_JETH. If the 
NMA$C_PCLI_PAD parameter is passed on a channel that does not have 
the NMA$C_PCLI_FMT parameter set to NMA$C_LINFM_ETH, the I/O 
request fails and you receive the error message SS$_BADPARAM. 


3.3.8 Ethernet/802 Drivers — Planned Change 

Software currently utilizing the promiscuous mode feature of the 
Ethernet/802 drivers may need to be modified to run properly on future 
releases of the operating system. (See Chapter 6 of the VAX/VMS I/O 
User's Reference Manual: Part II for a description of these drivers.) Since the 
Ethernet/802 drivers now allow a wide variety of packets to be transmitted 
and received, some restrictions will be placed on channels that turn on the 
promiscuous mode (NMA$C_PCLI_PRM) parameter. When this parameter 
is turned on, the following rules will apply: 

• Both Ethernet and IEEE 802 formatted packets will be received. The P5 
buffer, if specified, must be at least 20 bytes long. 

• Only one type of packet may be transmitted: either Ethernet or IEEE 
802. The value of the NMA$C_PCLI_FMT parameter will be used to 
determine which format will be used for transmissions. 

• The NMA$C_PCLI_PAD parameter will be ignored during READ 
operations on channels that are running in promiscuous mode. 
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• The promiscuous mode channel may not be put into SHARED access 
mode. Attempts to put the promiscuous mode channel into shared mode 
will result in an SS$_BADPARAM error. 

Applications using the promiscuous mode feature should note these planned 
restrictions. Those applications should be modified to run within these 
restrictions before the restrictions are applied and shipped in the VAX/VMS 
Ethernet/802 drivers. 


3.3.9 Ethernet Controller — List of Expected Errors 

Some Ethernet controllers support features that allow them to communicate 
with the hardware outside the VAX system to detect hardware failures. If 
the hardware connected to the Ethernet controller does not support these 
"hardware failure detection" features, then the controller and driver will 
report errors that are not true errors. 

To facilitate the detection of true errors, use the following list of "expected" 
errors to eliminate those errors caused by the lack of hardware failure 
detection support: 

• When using the DEQNA with the DECOM transceiver, a "Send failure" 
with reason code "Short circuit" is reported for each packet transmitted. 

• When using the DEUNA or DELUA with broadband, a "Collision detect 
check failure" is reported for each packet transmitted. 

See Section 6 of the VAX/VMS I/O User's Reference Manual: Part 11 for a 
discussion of these controllers. 


3.4 System Programmer Information 

This section describes problems resolved in VAX/VMS Version 4.7, lists 
known restrictions, and contains other information of interest to the system 
programmer. 


3.4.1 IOC$ALLOSPT Routine Will be Replaced 

The IOC$ALLOCPT routine, documented in Appendix A of the VAX/VMS 
Supplemental Information , Version 4.7, will be replaced by a new routine in the 
next release of the operating system. 


3.4.2 IO$M_RESET Modifier 

Prior to Version 4.2, the IO$M_RESET function modifier had the same value 
as the IO$M_INHERLOG modifier, which inhibits error logging. Because the 
IO$M_RESET bit was used only by the DR11-W driver. Version 4.2 changed 
the value of IO$M_RESET to decouple it from the IO$M_INHERLOG bit. It 
is important to note that the change also affects user-written drivers that use 
the IO$M—RESET modifier. 

To avoid possible problems, you should concurrently reassemble the 
following: 

• All user-written drivers that use the IO$M—RESET modifier 
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All programs that perform QIOs to user-written drivers that use the 
IO$M_RESET modifier 


3.4.3 LPA11 -K Driver (LADRIVER) — Changing Timeouts Allowed 

The driver for the LPA11-K (LADRIVER) times out all $QIOs after two 
seconds if they have not completed. The driver does not provide any 
parameters that allow the user to change the length of the timeout. 

In VAX/VMS Version 4.4 and subsequent versions, the timeout period that 
is applied to all $QIOs can be changed with the following patch commands 
executed from a suitably privileged account: 

$ PATCH SYSSSYSTEM:LADRIVER.EXE/OUTPUT=SYS$SYSTEM:LADRIVER.EXE 
PATCH> SET ECO 25 

PATCH> REPLACE/INSTRUCTION LA$TIMEOUT_VALUE 
0LD> 'PUSHL I~#00000002' 

0LD> EXIT 

NEW> 'PUSHL I~#0000003C 1 

NEW> EXIT 
PATCH> UPDATE 
PATCH> EXIT 

Substitute the desired timeout value for the "0000003C" in the example above. 
When you reboot, the system loads the new copy of the driver containing the 
new timeout value. 


3.4.4 Processor Register Definition Symbols 

The following internal processor registers (IPRs) are no longer common to all 
VAX processors. Their definitions have been removed from $PRDEF. 

• NICR—Interval Clock Next Interval Register 

• ICR—Interval Clock Interval Count Register 

• TODR—Time of Day Register 

• ACCS—Accelerator Control Status Register 

• ACCR—Accelerator Reserved 

• PME—Performance Monitor Enable 

New CPU-specific processor register definition macros have been added to 
STARLET.MLB to define the CPU-specific IPRs. The macro names have the 
format $PRxxxDEF, where xxx is the number associated with the processor 
(for example, $PR780DEF will define PR780$_ACCS). 

The only legitimate references to these registers are in CPU-dependent code. 
These references must use the new CPU-dependent IPR definitions. 

Note, however, that time-wait loops must never directly reference the clocks. 
They must use a time-wait macro that is independent of the CPU. A new, 
CPU-independent, time-wait macro called TIMEDWAIT has been added to 
LIB.MLB. This should eliminate any need for hand-coded, time-wait loops. 
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There should no longer be any references to PR$_ICR or PR$_TODR to 
do time-wait loops. TIMEDWAIT allows for up to six special-purpose 
instructions to be placed in its timing loop. However, the loop timing is based 
on having one BITx and one conditional branch instruction embedded within 
the loop. Therefore, if you have a loop with no embedded instructions, you 
may want to adjust the TIME argument accordingly. A good rule of thumb 
is to add 25 percent to the time argument if the loop has no embedded 
instructions. 

To reference PR$_TODR for logging purposes, use EXE$READ_TODR and 
EXE$WRITE_TODR. These two, new, loadable, CPU-dependent routines 
have been added for code that must reference this type of value. 


3.4.5 NETACP Verification of MOP Messages 

Version 4.7 of the network ancillary control program (NETACP) performs 
some verification before it starts up a maintenance operation module (MOM) 
process to service an incoming maintenance operation protocol (MOP) 
request. The VAX/VMS Networking Manual discusses these topics. 

NETACP starts up a MOM process under any one of the following conditions: 

• The request is not directed to a multicast address. 

• The source node specified in the MOP request is defined in the volatile 
node database. 

• The MOP message requests an operating system and contains the 
software identification of the file to be loaded. 

• The MOP request is not a program load. 

If NETACP does not start up a MOM process, it generates an event message 
of type 0.7 (aborted service request, line open error). The Ethernet address of 
the source node is also displayed with the message. 
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This appendix contains a listing of the patches, new images, and 
miscellaneous fixes contained in the Version 4.7 update kit. The following 
listing is obtained from the file SYS$UPDATE:VMS047.TXT, which is 
produced by the installation procedure if you select option 2 or 3 in 
step 4 of Section 1.4. 

Note: If you upgraded a VMS Version 4.6A system, the AUTOGEN patch 
(number 3) will not appear in your listing. Version 4.6A contains this 
patch. 

1) ADARTL (patch image) 

! ADARTL.EXE 

j 

! EC001 SBL 7-JUL-1987 

! Module: ADA$P0WER (X-2) 

i 

! Properly detect CONSTRAINT.ERROR if exponentiation of 

! a SHORT.INTEGER or SHORT.SHORT.INTEGER would overflow 

! the base type in VAX Ada programs. 


2) AGEN (miscellaneous fix) 

! AUTOGEN.VUG 

j 

! EC001 GHC0001 24-Aug-1987 

! MODULE: AUTOGEN 

! Apply the PE5 checksum fix only on V4.6 systems since the fix 

! is already in V4.6A. 

3) AUTOGEN (edit text file) 

! AUTOGEN.COM 
| 

! EC001 GHC0001 14-Aug-1987 

! MODULE: AUTOGEN 

! 1. Set PE5=2 on LAVC members with QNAs to turn on receive 

! packet checksumming. 

! 2. Guarantee that VMSIMAGES.DAT gets created on LAVCs. 

! 3. Consider VAX8530 a big boot node in LAVCs. 


4) BACKUP (patch image) 

! BACKUP.EXE 

i 

! EC0001 KGWE010 3-Jun-1987 00:04 

! Change version number to V4.7. 
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5) CLUSTRLOA (new image) 

! CLUSTRLOA.EXE 

I 

! EC001 WES 27-May-1987 

! 

! Module: CNXMAN 

! Change the protocol version and cluster version number for 

! V4.7. Prevent communication with V4.5 and previous. 

! 

! Module: FALMAN 

! Remove the failover table that was used for compatibility 

! with V4.5. 

! 

! Module: DISTRLKI 

! Begin filling in some new fields in the standard information 

! request message. 

j 

! WES 22-Jun-1987 

! 

! Module: CSPCALL 

! Indicate operation complete before sending a response 

! message to prevent waiting for piggyback acknowledgments. 

j 

! EC002 WCY 18-Sep-1987 

i 

! Module: CONMAN 

! Fix VAXcluster shared resource problem 

j 

! Module: CONUTIL 

! Fix VAXcluster shared resource problem 

j 

! Module: CNXMAN 

! Fix VAXcluster shared resource problem 

! 

! Module: QUORUM 

! Fix VAXcluster shared resource problem 

! 

! Module: CLUSTER.SDL 

! For the fix of VAXcluster shared resource problem: 

! Add definitions for ENTR and JMSG new messages. 

! Add new $CLUCFDEF and define current protocol ECOLEVEL 

! in SCNCTDEF. 

6) COBRTL (miscellaneous fix) 

i 

! COBRTL.EXE 


7) COBRTL (new image) 

! COBRTL.EXE 
! 

! EC001 DJM1001 15-May-1987 

! MODULE: COBRTL 

! Replace entire COBRTL image. This COBRTL supports the 

! COBOL 85 standard. It is being provided in a maintenance 

! release in order to greatly facilitate ANSI validation. 
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8) CSP (new image) 

! CSP.EXE 
! 

! EC001 WCY 18-Sep-1987 

i 

! Module: CSP.B32 

! Add the call to routine CSP$$CLUSTER_FILE 

! for the fix to VAXcluster shared resource problem. 

! 

! Module: CSPCLUFILE 

! This new module is to handle the open/create of the 

! CLUSTER.DAT file. 

9) CTDRIVER (patch image) 

! CTDRIVER.EXE 
| 

! EC001 JLV0001 28-May-1987 

! MODULE: CTDRIVER.EXE 

! Change CLRL to CLRW. 

10) DEBUG (patch image) 

! DEBUG.EXE 

i 

! EC0001 RT July 6 1987 

! Fix control-Y-DEBUG problem. 


11) DSDRIVER (miscellaneous fix) 

! DSDRIVER.MSKEXE 

j 

! SD0001 25-Aug-1987 

! MODULE: DUSHADOW.MAR 

! When HSC's failover shadow sets, if all member units 

! do not appear in the same 1 second interval on the 

! second HSC and if one of the units that does appear 

! is the highest numerical unit number in the set, disks 

! will be dropped from the shadow set. 


12) ERFCTLSHR (patch image) 

! ERFCTLSHR.EXE 

i 

! EC001 RAP0270 27-Jul-1987 

! MODULE: CONVERT.B32 

! - Add 1 longword to the V5.0 header size. 


13) ERFLIB (miscellaneous fix) 
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14) ERFPR0C1 (patch image) 

! ERFPR0C1.EXE 

i 

! EC001 AJM0157 25-May-1987 

! MODULE: MSCPDTDSP.B32 

! - Add TA79 recognition. 

j 

! EC002 AJM0160 26-May-1987 

! MODULE: STSEVENT.B32 

! - Add TK70 recognition. 

! - Correct TK50/TK70 data error limits 

! MODULE: TKXXDVDP.B32 

! - Correct Tk50/Tk70 drive fault code limits 


15) ESDRIVER (patch image) 

! ESDRIVER.EXE 

i 

! EC001 DAG0001 18-Jun-1987 

! MODULE: ETHERNET_CMN_RTN.MAR 

! Fix the SQUEEZ_MULTI routine so that operates properly. 

16) ETDRIVER (patch image) 

! ETDRIVER.EXE 

i 

! EC001 DAGOOOl 18-Jun-1987 

! MODULE: ETHERNET_CMN_RTN.MAR 

! Fix the SQUEEZ_MULTI routine so that operates properly. 

! EC002 DAG0065 26-Jun-1987 

! MODULE: ETDRIVER.MAR 

! Fix the 802 cannot receive problem. 

! EC003 DAG0073 07-0ct-1987 

! MODULE: ETDRIVER.MAR 

! Flush cached receive buffers after protocol shutdown. 

! EC004 DAG0073 07-0ct-1987 

! MODULE: ETDRIVER.MAR 

! Increase transmit and command timeout values from 3 to 5. 

! EC005 MJC0105 27-0ct-1987 

! MODULE: ETDRIVER.MAR 

! Fix NOIOCHAN and INSFMEM problem in ETDRIVER. This problem 

! was caused by insufficient clean up of a protocol termination. 


17) F11BXQP (new image) 

! F11BXQP.EXE 

i 

! EC002 KGW00109 l-Jul-1987 

! MODULE: MODIFY 

! Replace module to return correct file protection 

! for a file re-protected against its owner. 


18) HSCPAD (patch image) 

! HSCPAD.EXE 

i 

! EC001 AJM0191 30-Sep-1987 

! MODULE: HSCPAD.MAR 

! - Initialize logfile buffer descriptor length field. 
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19) JOBCTL (new image) 
! JOBCTL.EXE 


RG 7-Jul-1987 

Performance Improvement: 

A performance improvement was made to the Job Controller 
in the area of queue file clean up. When a node leaves 
the cluster all the surviving Job Controllers react to that 
event. This fix cuts down on some unnecessary redundancy. 

Module: BUFFERS.B32 

The queue file lock is now ENQed with the lock value 
block bit set. Also, the SS$_VALNOTVALID error is handled. 

Module: INITQUEUE.B32 

Again, ENQing the queue file lock with the lock value block 
bit set. 

Module: CONTROL.B32 

Instead of just doing "clean up" for a node leaving the 
cluster a decision based on the contents of the lock value 
block is made as to whether or not it should be done. 

File: JOBCTLDEF.REQ 

The lock value block is added to own storage. 


20) LATCP (new image) 

! LATCP.EXE 
! 

! EC001 JFC0015 25-Jun-1987 

! MODULE: LATCP 

! Move message array from kernel mode stack to own storage. 


21) LATSYM (new image) 

! LATSYM.EXE 
! 

! 47-015 WMF0003 14-0ct-1987 

! Module: DISPATCH 

i 

! Fix PSM$REPORT to supply the real error status to the 

! output completion routine. 

! Have [WRITE_COMPLETION] dispatch state look at error returned 

! from [WRITE] and have it pass on the error status to [READ]. 

! Force PSM$V_RESET in case a hard error was detected on an 

! output function. 


EC001 JFC0014 3-Jun-1987 

MODULE: LAT$$OUTPUT 

Fix timing window that caused queue to pause while 
printing multiple short files to a DECserver. 
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22) LTDRIVER (patch image) 

! LTDRIVER.EXE 
| 

! EC001 CAM0017 12-May-1987 

! MODULE: LTDRIVER 

! Use INCONSTATE instead of BADMCKCOD as bugcheck reason code. 

i 

! EC002 CJA0003 14-May-1987 

! MODULE: LTDRIVER 

! Fix 8800 crash when you use the LATCP command 

! STOP NODE. 

! 

! EC003 CJA0004 27-May-1987 

! MODULE: LTDRIVER 

! Fix rare crash in LTDRIVER when stopping a circuit. 

j 

! EC004 CJA0005 27-May-1987 

! MODULE: LTDRIVER 

! Fix some hung port problems associated with 

! "repeat create of slot by server" error. 

I 

! EC005 CJA0006 29-Aug-1987 

! MODULE: LTDRIVER 

! In L00P_AB0RT, just turn around a STOP SLOT using the 

! received SRCID. DOn't harm the target UCB since it's 

! probably not the guilty party. 

i 

! EC006 CJA0007 13-0ct-1987 

! MODULE: LTDRIVER 

! Fix system crasher on CONNECT and DISCONNECT functions 

! when we get a virtual UCB instead of physical. 

23) MOM (patch image) 

! MOM.EXE 
! 

! EC0001 TRC0118 30-Sep-1987 

! MODULE: M0MM0PLI0 

! Inhibit attempt to read the NI header if a point-to-point 

! circuit is being used. 

! 

! EC0002 TRC0119 30-Sep-1987 

! MODULE: MOMSERVIC, M0MM0PLI0, MOMLOAD 

! Add code to properly handle the initial MOP message on 

! point-to-point circuits. 

I 

! EC0003 TRC0120 30-Sep-1987 

! Format status text in error messages/events. 

! TRC0121 30-Sep-1987 

! Ensure loop message length is correct for circuit loopback. 

! TRC0122 30-Sep-1987 

! Allow graceful exit from circuit loopback. 
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24) MONITOR (patch image) 

! M0NIT0R.EXE 

i 

! EC0001 SAH 15-Sept-1987 

! MONITOR\RECORD_HEADER 

! Record initial system information records only if the 

! node is currently active. 

i 

! EC0002 SAH 18-Sept-1987 

! Ignore status returned from LIB$FREE_VM in cleanup 

! routines. 

i 

! Set the correct ECO level 


25) MTAAACP (patch image) 

! MTAAACP.EXE 

i 

! EC001 KGW00114 7-Jul-1987 

! MODULE: HEADER 

! Issue a reposition-to-zero to workaround a TK50 

! limitation with serious exception handling. 


26) NETACP (patch image) 

! NETACP.EXE 
! 

! ECO 01 Reserved by Terry 
! 

! ECO 02 WXD0031 18-Mar-1987 

! MODULE: NETDLLTRN - code 

! Fix NETNOSTATE from processing a CXB queued for 

! an adjacency that has since been reused. 

i 

! ECO 03 LY0003 21-MAY-1987 

! MODULE: NETCONFIG - tables impure psect 

! Disallow the MAX BROAD ROUTERS parameter from changing 

! while DECnet is running 

i 

! ECO 04 TH0004 25-MAY-1987 

! MODULE: NETPROCRE - code 

! Allow for both old and new link Id formats in during the 

! rolling upgrade from V4.7 to V5.0. 

! This entails not allowing the top bit in the link ID to 

! be set - this corresponds to the new format cluster alias flag. 

j 

! ECO 05 WXD0037 15-Jun-1987 

! MODULE: NETCNFDLL - code 

! Don't change the default protection of any device except 

! for Ethernet devices. 

! 

! ECO 06 RBH0001 18-JUN-1987 

! MODULE: NETDLLTRN - code 

! When the number of DLM/X.25 circuit recalls wrap around 

! from 255 to 0, treat number 0 as the limit to stop making 

! call. 

i 

! ECO 07 RBH0002 29-JUN-1987 

! MODULE: NETCONECT 

! Fix cluster alias problem involving a DECSA router box. 

! The fix is not to accept the offered segment size, but 

! use the executor segment size. 
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! ECO 08 WXD0042 14-Sep-1987 

! MODULE: NETCLUSTR 

! Fix cluster alias problems which occur when a cluster 

! member runs out of alias logical links. 

! 

! ECO 09 TRC0124 1-Oct-1987 

! MODULE: NETCNFDLL 

! Fix X-18N3 so ignoring of RIS timer is done if circuit is in 

! MOP mode rather than in autoservice substate. 

i 

! ECO 10 TRC0126 l-0ct-1987 

! MODULE: NETCONFIG 

! Modify version number for V4.7. 

i 

! ECO 11 RBH0003 06-0CT-1987 

! MODULE: NETCONECT 

! Fix cluster alias problem involving a DECSA router box. 

! If a router in the cluster accepts an incoming connect, 

! NETACP uses the large buffer size. The fix is to not 

! treat the cluster router as a special case. 

j 

! ECO 13 Reserved by Sherry 

i 

27) NETDRIVER (patch image) 

! NETDRIVER.EXE 

i 

! ECO 001 TH001 25-MAY-1987 

! MODULE: NETDRVNSP.MAR 

! Allow for both old and new link Id formats in during the 

! rolling upgrade from V4.7 to V5.0. 

! This entails checking the cluster alias id flag in both 

! locations in the Id. and then extracting the cluster node 

! index accordingly. 

i 

! ECO 002 RBH0001 26-MAY-1987 

! MODULE: NETDRVXPT.MAR 

! Fix bug in endnode cache to remove stale entry when 

! node is switched from an Ethernet circuit to other 

! circuit. 

i 

! ECO 003 WXDNNNN 
! MODULE: NETDRVXPT.MAR 

! Clear congestion flag in 

! aged packet loss. 

I 

! ECO 004 SAS0018 17-Jun-1987 

! MODULE: NETDRVSES.MAR 

! Fix timing window bug in io$_deaccess processing. 

! Clear the xwb$m_flg_sdt flag to dismiss transmission 

! of suspended threads. 

j 

! ECO 005 SAS0025 05-0ct-1987 

! MODULE: NETDRVQRL.MAR 

! Create a second patch area in the obsolete NETDRVQRL module. 

I 

! BECAUSE PATCHES MAY BE APPLIED TO PARTIALLY PATCHED IMAGES 

! IT IS NECESSARY FOR EVERY ECO AFTER ECO 005 TO EXPLICITLY 

! DO A "SET PATCH NETDRVQRL+173" WITHIN THEIR SET ECO CONTEXT. 


16-Jun-1987 

short format messages to prevent 
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ECO 006 SAS0024 
MODULE: 
Fix bug 
Fix bug 


30-Sep-1987 

NETDRVNSP.MAR 

in receive IO$M_MULTIPLE code on clone CXB failure, 
in ss$_dataoverun processing of OVF state transitions. 


28) NODRIVER (new image) 

! NODRIVER.EXE 
! 

! MJC 29-Sep-1987 

j 

! This version of NODRIVER is a replacement of the current 

! NODRIVER. This driver contains fixes to correct problems 

! in receive message processing. 


29) PEDRIVER (miscellaneous fix) 

! PEDRIVER.MSKEXE 
! 

! EC002 JAY 20-Jul-1987 

! Fix PE.CONFIG to properly handle an invalid event in 
! in its state table processing. Also, add more CXBs. 

! 

! EC001 KP 16-Jun-1987 

! Fix PEM_CC so that, if the password in a channel control 
! message doesn't match the cluster password, then the node 
! that sent the message is ignored. 


30) RMS (patch image) 


RMS.EXE 


ALL PMV0054 08-Jul-1987 

MODULE: (none) 

Modify all existing ECOs to check for existence of 
ECO 96. If present, this indicates that RMS Journaling 
has been installed, and the ECO should not be applied. 

ECO 1 PJH 07-Jun-1987 

MODULE: RMOSHARE 

Backout use of blocking ASTs on file locks introduced in 
V4.4. 


ECO 2 LSS 10-Jun-1987 

MODULE: RMORECLCK 

Prevent all reclamation of RU deleted UDRs, RRVs, and SIDRs 
by always returning a zero status from RM$QUERY_PROC. 

ECO 3 PJH 19-Jun-1987 

MODULE: RM1C0NN 

For now, turn off Deferred Write when a sequential file is 
opened for shared append access. 


ECO 


4 


JEJ 

MODULE: RM1PUT 

$PUT operations with UIF 

SRELEASE operation would 


26-Jun-1987 

set to the current record after a 
fail with RMS$_RNL. 
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ECO 5 JWT 29-Jun-1987 

MODULE: RM3KEYDSC 

Tighten up the check for supported key types when an indexed 
file is opened. 

ECO 6 SAD043 06-Jul-1987 

MODULE: RMOCACHE 

Cached buffers are only valid for BDB$W_NUMB bytes. If 
a request to read more than the cached bytes, the remainder 
must be read from disk. 

MODULE: RM1NXTBLK 

To eliminate excessive incremental reads form the change to 
RMOCACHE, issue cache requests thru HBK, rather than EBK. 

ECO 7 LSS0058 29-Sep-1987 

Prevent a problem where a change in the state of the FAB$V_CIF 
bit during a SCREATE operation on an indexed file can result 
in the over-writing of the prolog, key, and area descriptors 
for an existing file as if it were just created. 

MODULE: RMOCRECOM 

Set IFB$V_CIF if about to do create-if access $QI0. 

Bit IFB$V_CIF is the spare IFAB book keeping bit IFB$V_TEF+1. 

MODULE: RM3CREATE, RM3FACE 

Check IFB$V_CIF instead of FAB$V_CIF to determine if create-if 
was attempted. 


31) SATELLITE.CONFIG (edit text file) 

! SATELLITE_CONFIG.COM 

i 

! EC001 CJB027 28-Sep-1987 

! Correct deletion of NETNODE_REMOTE.DAT. 


32) SECURESHR (patch image) 

! SECURESHR.EXE 
! 

! EC001 DDP0230 06-0CT-1987 13:41 

! MODULE: SYSUAISRV 

! Miscellaneous bug fixes. 


33) SET (patch image) 

!SET.EXE 

i 

! EC001 LMP0444 22-May-1987 

! MODULE: SETFILE 

! This change modifies which (RMS) device name is used when 

! assigning a channel for the actual QIOs. Use of the DEV device 

! name caused problems when dealing with search lists. (DVI is 

! the correct field.) 
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34) SMBSRVSHR (new image) 

! ++ 

! SMBSRVSHR.EXE 

i 

! EC00001 MTR0001 13-July-1987 

! 

! This image replacement fixes 4 specific problems. 

! Determination of printable characters. 

! Page accounting when printing /NOFEED. 

! Print documents from queues with form attribute /SHEET.FEED. 
! Device control libraries and main input files left open. 


35) STABACKUP (patch image) 

! STABACKUP.EXE 
! 

! EC0011 KGWE0011 3-Jun-1987 00:04 

! Change version number to V4.7. 


36) SYS (patch image) 
! SYS.EXE 


The following patches are part of the mandatory update for VAX/VMS Version 4.6. 

EC080 KFG0001 06-Jul-1987 

MODULE: SYS.EXE 

Set system version number to "V4.6". 

All patches related to the VAX/VMS Version 4.7 maintenance release should be added 
after this point. This is to insure that all of the patches for the VAX/VMS Version 
4.6 mandatory update are applied prior to any of the 4.7 related patches. 

EC085 LMP0450 21-Apr-1987 

MODULE: SYSCHKPRO 

Reinitialize ACE pointer (Rl) when checking a multi¬ 
segment ACL for audit ACEs. 

EC086 LMP0450 6-MAy-1987 

Make sure we don't branch into the middle of an 
instruction. 


EC087 WMC0087 26-May-1987 

MODULE: SYSLKWSET 

Make SCNWSLX scam backwards from WSNEXT, then forwards. 


EC089 WMC0089 25-Jun-1987 

MODULE: PHDUTL 

Correctly check PHD size in MMG$ALCPHD. 


EC091 JLW0091 07-Jul-1987 

Change system version number to X4.7 (field test version) 

EC092 JLW0091 05-0ct-1987 

Change system version number to Y4.7 (ft2) 

EC093 SHD0023 27-Jul-1987 

Fix I0PERF0RM allocate routine to check for null UCB 
pointer 
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EC094 

SHD0026 

03-Aug-1987 


Fix EC0_66 to 
structures. 

account for V4.7 MSCP server data 

EC095 

LJK4036 

11-Aug-1987 


Remove ECO 66 

as part of backing out the V4.7 MSCP server 

EC099 

JLW0091 

28-0ct-1987 


Change system 

version number to V4.7 


! Define the following symbols so that the patches can be reapplied. 

37) SYSINIT (new image) 

! SYSINIT.EXE 

i 

! EC001 WCY 18-Sep-1987 

! 

! Module: SYSINIT.MAR 

! Add reading of CLUSTER.DAT file in SIP_CLUSTER_INIT 

! routine for the fix to VAXcluster shared resource 

! problem. 

38) SYSL0A790 (new image) 

! SYSL0A790.EXE 
! EC001 

! Module: MCHECK790 

! New machine check handler. Fixed some typo's 

! that made an incorrect mask for abort bits. 

! Looked in the correct register for PROC ABORT 

! Allowed the ability to retry instructions 

! for more failure scenarios. 

39) SYSL0A8NN (patch image) 

! SYSL0A8NN.EXE 
! 

! EC001 CBD0125 l-Jul-1987 

! MODULE: SYSL0A8NN 

! Add missing # to TIMEDWAIT in STARTIO 

i 

! EC002 CBD0161 27-0ct-1987 

! MODULE: SYSL0A8NN 

! Remove JSB to output of cache off sue to errors message. 

! Cache being turned off will not be reported. 

! 

40) TPUSHR003 (patch image) 

! TPUSHR.EXE 

j 

! EC003 BMT0001 14-Sep-1987 

! MODULE: TPUSHR.EXE 

i 

! Allow TPU to send any characters in the range Al-FE to 

! the terminal. 
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41) TTDRIVER (new image) 

! TTDRIVER.EXE 

i 

! JJF 29-Sep-1987 

! 

! A new TTDRIVER is provided in the VMS V4.7 kit. This TTDRIVER 

! has a change so that VMS workstations using terminal emulator 

! windows will work correctly. 


42) TUDRIVER (patch image) 

! TUDRIVER.EXE 

i 

! EC001 MAS0154 16-Jun-1987 

! MODULE: TUDRIVER 

! Allow dismounting of tape drives on non-functioning 

! controllers to proceed. 

j 

! EC002 PRD0346 04-Jun-1987 

! MODULE: TUDRIVER 

! Modify AUTOPACK_ACK to retry a request rather 

! place it on the I/O pending queue if in 

! single-stream mode. 

i 

! EC003 MAS0156 7-Jul-1987 

! MODULE: TUDRIVER 

! Do not update position information on invalid 

! modifier processing. 

i 

43) TVDRIVER (new image) 

! TVDRIVER.EXE 

j 

! EC002 RNH 14-Jul-1987 

! Module: TVDRIVER 

! Return correct record length when returning SS$_WASECC. 

! 

i 

! EC001 RNH 07-Jul-1987 

! Module: TVDRIVER 

! Fix assumptions which prevented DMA if records were >12KB. 

! >12KB writes disabled (SS$_BADPARAM) to aid in V4.7 stability. 

! Fix bugs which omitted setting BOT in some situations and 

! which omitted logging correctable ECC errors. Always include 

! IRP trace code, but switch off its execution. Return 

! SS$_MED0FL for timeouts during the SCSI Selection phase. 

44) UETDISKOO (new image) 

! UETDISKOO.EXE 


EJM 29-Jul-1987 

Module: UETDISKOO.MAR 

Change initial file creates to seven blocks in one shot 
mode (from 5% of free space) to speed up testing. 
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45) UETINITOO (patch image) 

! UETINIT00.EXE 
! 

! EC001 LDJ0001 ll-Jun-1987 

! MODULE: UETINITOO.MAR 

! Do not report an error if there is more than the required 

! amount of quotas in the SYSTEST account. 

46) UETINIT01 (new image) 

! UETINIT01.EXE 


EJM 27-Jul-1987 

Module: UETINIT01.MAR 

Allow user specified timeout for init stage. The logical 
(UETP$INIT_TIMEOUT) must be specified in delta time format 
(default "0 00:06:00"). 


47) UISSHR (new image) 

! UISSHR.EXE 
! 

! EC001 JJF0001 7-Jul-1987 

! MODULE: UISSHR 

! Replace entire UISSHR image. This updates the UISSHR image 

! with all entry points as of Version 3.2 of VWS. 


48) VAXCRTL (miscellaneous fix) 

i 

! VAXCRTL.OLB 


49) VAXCRTL (patch image) 

! VAXCRTL.EXE 
! 

! EC001 CHH0061 01-jun-1987 

! Module: CSMALLOC (061) 

! Incorrectly zeroing out MRF block in malloc/free 


The following symbols applies to ECO 01 


50) VAXCRTLG (patch image) 

! VAXCRTLG.EXE 
! 

! EC001 CHH0061 01-jun-1987 

! Module: C$MALL0C (061) 

! Incorrectly zeroing out MRF block in malloc/free 

i 

! 

! The following symbols applies to ECO 01 
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51) VMB (new image) 

! VMB.EXE 
! 

! EC001 EJL0160 06-Jun-1987 

! MODULE: PABTDRIVR 

! Correct double deallocation error and increase retry counts. 

! This ECO improves the ability of the boot driver to write a 

! crash dump to an HSC disk over the Cl. 

i 

52) VPM (patch image) 

! VPM.EXE 

i 

! EC0001 SAH 04-June-1987 

! Module: PSLREMOTE\PSL$REMOTE_CALL 

! A check to make sure that all incoming requests to the Monitor 

! server process were compatible with the local version needs 

! to be modified to handle V5 requests. The V5 code changed after 

! this code was added to V4.6. Most of the V4.6 code added is 

! obsolete and is being removed 


Set the ECO level... 


53) XGDRIVER (new image) 

! XGDRIVER.EXE 

i 

! MJC 29-Sep-1987 

i 

! This version of XGDRIVER is a replacement of the current 

! XGDRIVER. This driver contains fixes to correct problems 

! in receive message processing. 


54) XQDRIVER (patch image) 

! XQDRIVER.EXE 

i 

! EC001 DAG0001 03-Jun-1987 

! MODULE: XQDRIVER.MAR 

! Do not ignore transmit packets that get errors. Instead, 

! remove them from the ring and let the rest of the transmit 

! code handle the error. 

! 

! EC002 DAG0002 18-Jun-1987 

! MODULE: ETHERNET_CMN_RTN.MAR 

! Fix the SQUEEZ_MULTI routine so that operates properly. 

55) YFDRIVER (new image) 

! YFDRIVER.EXE 

j 

! EC001 FAK 07-JULY-1987 

I 

! Replace YF$AB0RT with V4.4 code the new YF$AB0RT logic added 

! in V4.6 can cause device to start producing DEVICE TIMEOUT 

! errors. 
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□ 

□ 

□ 

□ 

Completeness (enough information) 

□ 

□ 

□ 

□ 

Clarity (easy to understand) 

□ 

□ 

□ 

□ 

Organization (structure of subject matter) 

□ 

□ 

□ 

□ 

Figures (useful) 

□ 

□ 

□ 

□ 

Examples (useful) 

□ 

□ 

□ 

□ 

Index (ability to find topic) 

□ 

□ 

□ 

□ 

Page layout (easy to find information) 

□ 

□ 

□ 
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I would like to see more/less 


What I like best about this manual is 


What I like least about this manual is 


I found the following errors in this manual: 
Page Description 


Additional comments or suggestions to improve this manual: 


I am using Version _ of the software this manual describes. 


Name/Title _ 

Company _ 

Mailing Address 


Dept. _ 

_ Date 


Phone 
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